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1. THE PROJECT 


1.1 Introduction 

This three-year project (February 1991 to February 1994) has involved analyzing 
and helping to design the communication network for the Advanced Solid Rocket 
Motor (ASRM) facility at Yellow Creek, near Iuka, MS. The principal concerns in the 
analysis were the bandwidth (both on average and in the worst case) and the 
expandability of the network. 

As the communication network was designed and modified, a careful evaluation of 
the bandwidth of the network, the capabilities of the protocol, and the requirements 
of the controllers and computers on the network was required. The overall network, 
which was heterogeneous in protocol and bandwidth, needed to be modeled, analyzed, 
and simulated to obtain some degree of confidence in its performance capabilities and 
in its performance under nominal and heavy loads. The results of our analysis did have 
an impact on the design and operation of the ASRM facility. 

1.2 Technical Issues 

Throughout the whole process the most debilitating aspect was the lack of 
communication requirements. As is discussed in detail below, numerous redesigns 
were required primarily due to “new” or “changed” data rates, data quantities, or 
transmission duty cycles (e.g., 80MB not having to be transferred in 100 secs, but in 
100 minutes). Insufficient priority was given to requiring the various “workcell 
owners” or “workstation users” to quantify their data transmission requirements. 

We sought to evaluate the node connections; the I/O rates, the I/O rate 
characteristics (burst, steady, batch, etc.), and memory buffer storage capacity of each 
node; the physical lengths of cable; and the bandwidth of each LAN, the bandwidth of 
the backbone, and the bandwidth to communicate offsite. Initially our primary 
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concern was the actual manufacturing area, but migrated to the Business Information 
System (BIS), since that became the most heavily loaded network ultimately. 

1.3 Summary of Steps 

A short summary of the interim final reports submitted in February 1992 and 
February 1993 and the rest of this final report is given below. 

In February 1991, the proposed Manufacturing network consisted of an FDDI ring 
off of which were connected five Ethernet fiber-based LANs and the OIS computer. 
This configuration was analyzed, the results were summarized, submitted, and 
subsequently accepted as a refereed paper in the IEEE Southeastcon ’92 conference. 
Several changes were made to the network as 1991 progressed. Once the OIS computer 
(a 4— machine VAXcluster) was procured, the FDDI ring disappeared and the 5 LANs 
were attached directly to the OIS computer. This configuration was simulated and the 
results discussed in Section 2 of the February 1992 interim final report. In July 1991, 
as the data rate requirements began to decrease, a data-over-voice network was 
proposed for non— critical sections of the network. The proposed network consisted of 
a hybrid of Ethernet— over— fiber and Intecom LANmark. This proposed network was 
discussed in Section 3 of the February 1992 interim final report. The two network 
technologies (Ethernet over fiber and LANmark) were tested on November 12—13, 
1991 and on December 12—13, 1991 in Iuka, MS at the ASRM facility and the results 
are discussed in Sections 4 and 5 of the February 1992 interim final report. Section 
6 of the February 1992 interim final report consisted of a summary and some 
conclusions on where the network stood and where the design seemed to be headed. 

In early 1992 we performed an extensive study of the X protocol and its effect of its 
utilization on the network, due to the vendors “offer” to provide X-terminals in lieu of 
the ASCII terminals specified in the bid. We confirmed that by changing the end— user 
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equipment from ASCII terminals to X— terminals, there would be a significant increase 
in the network traffic. 

As 1992 progressed, the proposed network changed again. By January 1993, the 
overall network structure had one logical FDDI ring acting as a backbone for the whole 
complex. The buildings were grouped into two categories, namely manufacturing 
critical and manufacturing non-critical. The manufacturing critical buildings were 
connected via FDDI to the Operational Information System (OIS) in the main 
computing center in building 1000. The manufacturing non-critical buildings were 
connected by 10BASE— FL to the Business Information System (BIS) in the main 
computing center. The workcells were connected to the Area Supervisory Computers 
(ASCs) through the nearest manufacturing critical hub and one of the OIS hubs. 

During 1993 we analyzed many configurations of this basic network structure. The 
analyses are described in detail in Section 2 and 3 herein. Section 2, Ravindra 
Nirgudkar’s master’s thesis, reports on an analysis of the whole network. The 
preliminary results of that research indicated that the most likely bottleneck as the 
network traffic increased would be the hubs. Thus a study of Cabletron hubs was 
initiated. The results of that study are in Section 3, which is James Dement’s master’s 
project. 

Section 4 herein reports on the final network configuration analyzed. When the 
ASRM facility was mothballed in December of 1993, this was basically the planned and 
partially installed network. 

A briefing was held at NASA/MSFC on December 7, ■ our final 

analysis and conclusions were disseminated. This repor record of 

most of the information disseminated at that briefing 
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2. SUMMARY OF COMPREHENSIVE NETWORK ANALYSIS 
(RAVINDRA NIRGUDKAR’S THESIS) 


2.1 Introduction 

The thesis (Appendix A) analyzes the communication network for the NASA 
Advanced Solid Rocket Motor (ASRM) facility which was under construction at Yellow 
Creek near Iuka, Mississippi. Manufacturing, testing, and operations were to be 
performed in various buildings scattered over a 1800 acre site. These buildings were 
to be interconnected through a Local Area Network (LAN), which was to contain one 
logical Fiber Distributed Data Interface (FDDI) ring acting as a backbone for the whole 
complex. The network was to contain approximately 700 workstations, 22 workcells, 
and 3 VAX clusters interconnected via Ethernet and FDDI. The different devices would 
have produced appreciably different traffic patterns, each pattern would have been 
highly variable, and some patterns would have been very bursty. Most traffic would 
have been between the VAX clusters and the other devices. Comdisco’s Block Oriented 
Network Simulator (BONeS) was used for network simulation. The primary 
evaluation parameters used to judge the expected network performance were 
throughput and delay. 

2.2 Summary of the Thesis 

The main aim of the thesis was to present the overall communication network 
structure for the ASRM facility. The thesis is composed of chapters discussing the 
ASRM communication network structure, the BONeS simulation of the ASRM 
network, and an analysis of the simulation results. 

The chapter on ‘ASRM Communication Network Structure’ concentrates on the 
network connectivity, cabling, and the different protocols used. This chapter also 
explains the flow of data in the network. 


4 



The chapter on ‘BONeS Modeling’ gives an overview of the BONeS simulator. This 
chapter also describes the different BONeS models developed to simulate the ASRM 
environment and the different probes and the iteration settings used. 

The ‘Analysis and Results’ chapter comments on the network expectations and the 
network evaluation parameters. The chapter also summarizes the various plots of 
Mean Delay and Throughput versus Traffic Intensity. 

The ‘Conclusion’ chapter at the end of the thesis summarizes the different findings 
from the simulation results. The chapter also makes an attempt to validate the 
simulation model and verify the simulation results. A few recommendations for 
further study is also provided at the end of that chapter. 

2.3 Research Objective 

The main objective of the research was to simulate and analyze the network to 
determine its performance under different conditions. The performance of the network 
with the given topology and protocols can be evaluated using BONeS. 

The two parameters viz. throughput and delay were used to judge the network 
performance. The aim of the simulations was to estimate the loading of the OIS, the 
BIS, the ASCs, and the network links due to the traffic generated by the workstations 
and the workcells over the entire site. 
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3. SUMMARY OF HUB ANALYSIS 
(JAMES DEMENTS PROJECT) 


3.1 Project Objectives 

The objectives of this project were two— fold. The first objective of this project was 
to design and build a model of the Cabletron Hub using the Block Oriented Network 
Simulator (BONeS) which was developed by Comdisco Systems, Inc. The second 
objective was to use this model in a network simulation to try and determine if the hub 
produced any bottlenecks that might be of importance to network designers, especially 
those involved in building the computer network at the Advanced Solid Rocket Motors 
(ASRM) plant in Iuka, Mississippi. 

3.2 Project Description 

The computer network system at the ASRM plant used Cabletron Multi Media 
Access Centers (MMACs) for its network interconnection. By studying the documents 
provided by Cabletron Systems, Inc. and by talking with the Cabletron technical 
personnel, it was possible to develop an understanding of how the Cabletron Media 
Interface Modules (MIMs) used at the ASRM facility interacted with each other. Using 
this information and the BONeS Block Diagram Editor, models were developed that 
would emulate the interaction and timing specification of the overall hub. By 
connecting the individual modules together, the completed hub could be used in 
network simulations designed to analyze the performance of the hub. 

3.3 Project Analysis and Conclusions 

Using BONeS, models of the individual Media Interface Modules (MIMs) were 
developed. Tests were then conducted on these modules and the results of the tests 
were compared to known results. According to Cabletron documentation, the tests 
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show that under all tested conditions, the software models produced the same 
performance measurements as the actual Cabletron Modules. This successfully 
concluded the first objective of the project. 

The second objective, to use the models in a network simulation to determine delays 
caused by bridge processing, could not be completed in the time given. Although the 
second objective was not completed, it is possible to make predictions as to what the 
outcome might be by examining the results of the first objective. Tests in the first 
objective indicated the bridge modules could filter packets as fast as the protocols could 
deliver them. Therefore, little or no buffering would occur and the total delay would 
be negligible when compared to delays incurred by collisions and other network delays. 
Since the bridge modules could not forward packets as fast as they could filter them, 
there is a possibility that packets might need to be stored in temporary buffers in the 
bridges. Preliminary tests show that even under abnormally high traffic conditions, 
the buffers become at most 45% full. 

3.4 Further Study 

Although preliminary tests indicated that there should be no problem with the 
buffering capacity of the bridges, further study should be conducted to assess the 
delays incurred by the buffering. There are two hubs in particular that might pose a 
problem in the ASRM network. The first hub is the hub used to bridge one of the ASCs 
to the FDDI backbone. The second hub is the BIS hub where there are multiple 10 
Mbps channels being fed into a single 10 Mbps channel. 
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4. NEW ASRM NETWORK 


4.1 Introduction 

On August 10, 1993, we were briefed in detail at the ASRM facility on the changes 
that had been made to the ASRM network up until that time. These changes were then 
incorporated into the existing network simulation and new simulations were 
performed. This chapter explains the changes made to the previous model, and 
compares the results of this new network model to those of the previous model. 

4.2 Changes in the ASRM Network 

• The two ASCs will be located one each in B_1000 and B_2029. 

• Since one ASC is removed from B_1000, the whole of the workcell traffic will 
not be flowing to B_1000. The workcells attached to B_2029 will now have 
different paths (different then workstations paths) from their building to the 
ASC. The paths will be 10BASEFL. 

• The ASCs will communicate with the OIS over the FDDI backbone. 

• All the workstations in the intensive buildings will now be on the FDDI 
backbone, i.e., intensive buildings will no longer have a non— intensive hub. 

• All the workstations connected to the purely non— intensive buildings will 
still communicate with the OIS through the BIS hub (same as before). 

• The 73 workstations in B_1000 will now be connected to the BIS hub instead 
of the OIS hub. 

• The following buildings have been deleted: B_1022, B_1025, B_1045, 

B_1032, B_2070, B_4001, B_3003, and B_3010. 

• The following buildings have been added: B_1002 and B_2015. 
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4.3 New ASRM Network Structure 


The new ASRM network structure will be as shown in figure 4.1 and 4.2. 
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Figure 4.2 ASRM Yellow Creek Site as on 10/23/93 
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The distances of each building from the nearest hub and the distances of the hubs 
from building 1000 for the new ASRM network are as given in Table 4.1 and 4.2 
respectively. 


Building 

No. 

Building Name 

No. of 
workstns 

No. of 
workcells 

Link 

Nearest 

Hub 

Distance 

from 

hub(feet) 

1000 

Engineering / 
Computer 

73 

00 

— 

1000 



1001 

Security and 
Medical 

03 

00 

Link #4 

1000 

1500 

1002 

Chemical Storage 

01 

00 

Link #4 

1000 

2600 

1010 

Central Warehouse 

10 

00 

Link #4 

1000 

600 

1016 

Case Prep, and 
Refurbishment 

27 

16 

Link #3 

1016 



2015 

Pre - Mix (Mix / Cast) 

11 

00 

Link #1 

2029 

1450 

2028 

Tool Clean / 
Core Prep. 

08 

00 

Link #1 

2029 

2600 

2029 

Remote Control 
Room 

12 

01 

Link #1 

2029 



2030 

Non Destructive 
Evaluation Facility 

03 

02 

Link #6 

2030 



2031 

Final Assembly 

15 

00 

Link #2 

2031 



2042 

Main Motor 
Storage 

04 

00 

Link #6 

2030 

8650 

2060 

Small Scale 
Propellant Proc. 

04 

02 

Link #1 

2029 

2250 

2066 

Quality Assurance 
Lab. 

05 

00 

Link #5 

2066 

— 


(continued on next page) 
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TOTAL 185 24 


Table 4.1 Distances of each building from the nearest hub 


Link Distance Number of Number of l^pe of the 

(feet) Workstations on Workcells Link 

the link. on the link. 

Link # 1 : 6700 40 04 Intensive 

(2029) 

Link # 2 : 4650 15 00 Intensive 

(2031) 

Link# 3: 1450 27 16 Intensive 

(1016) 

Link #4: 00 (14 + 73) 00 Non-intensive 

(1000) + BIS Devices 

Link # 5 : 3550 05 00 Non-intensive 

(2066) 

Link # 6 : 5000 11 02 Intensive 

(2030) 

Link # 7 : 950 14 BIS w/s 00 Non-intensive 

( 1012 ) 


Table 4.2 Distance of the hubs from Building 1000 
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4.4 BONeS models for the New ASRM Network 

The BONeS models for the modified ASRM Network are as shown in figures 4.3, 
4.4, 4.5, and 4.6. 
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Figure 4.3 ASRM network Model 
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Figure 4.5 Intensive building 2029 Model 
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Figure 4.6 Intensive building 2030 Model 





4.5 Mean Delay and Throughput plots 

Various simulation runs were made on the new ASRM network model by setting the 
simulation time per iteration to one and five seconds. Also a simulation run of five 
seconds was made on the new ASRM network model without the BIS network to study 
the effect of the BIS network on the overall network. The mean delay per packet and 
throughput are plotted versus the offered traffic intensity. The mean delay per packet 
and throughput versus the offered traffic intensity are plotted in figures 4.7 to 4.22. 
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BIS Network Delay Comparison Plot 



20 . 40 . 60 . 80 . 


Traffic Intensity / Node (Kbps) 

■ B_2087_NI D RM 507 0 MAC Network 

• RM 638A a Printer 


Figure 4.7 BIS delay plot for simulation time of 1 second 
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BIS Network Throughput Comparison Plot 
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Figure 4.8 BIS devices throughput plot for simulation time of 1 second 
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Intensive Network Delay Comparison Plot 
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Figure 4.9 Intensive network delay plot for simulation time of 1 second 
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Intensive Network Throughput Comparison Plot 
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Figure 4.10 Intensive network throughput plot for simulation time of 1 second 
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Non-lntensive Network Delay Comparison Plot 
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Figure 4.11 Non— Intensive network delay plot for simulation time of 1 second 
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Non-lntensive Network Throughput Comparison Plot 
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Figure 4.12 Non-lntensive network throughput plot for simulation time of 1 

second 



24 


o 

<D 

C/5 

> 

05 

Q 



BIS Network Delay Comparison Plot 
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Figure 4.13 BIS devices delay plot for simulation time of 5 seconds 
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Figure 4.14 BIS devices throughput plot for simulation time of 5 seconds 
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Mean Delay (msec) 


Intensive Network Delay Comparison Plot 
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Figure 4.15 Intensive network delay plot for simulation time of 5 seconds 
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Figure 4.17 Non— Intensive network delay plot for simulation time of 5 seconds 
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Non-lntensive Network Throughput Comparison Plot 
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Figure 4.18 Non-lntensive network throughput plot for simulation time of 5 

seconds 
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Figure 4.19 Intensive network delay plot for simulation time of 6 seconds 

without the BIS devices 
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Intensive Network Throughput Comparison Plot 
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Figure 4.20 Intensive network throughput plot for simulation time of 5 seconds 

without the BIS devices 
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Figure 4.21 Non-Intensive network delay plot for simulation time of 6 seconds 

without the BIS devices 
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Figure 4.22 Non— Intensive network throughput plot for simulation time of 5 

seconds without the BIS devices 
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4.6 Analysis of the Results 

The mean delay per packet versus the offered traffic intensity plots obtained for the 
modified network are similar to that of the previous network except for the maximum 
value of the delay. The curves in the throughput versus the offered traffic intensity 
plots show that the throughput increases linearly with the offered traffic intensity per 
node, similar to that of the previous network. 

The major differences between the plots for the new network and that of the 
previous network are as follows: 

• There is a significant increase in the maximum delay value for the BIS 
sub-networks. This change can be attributed to moving the 73 OIS 
workstations from the OIS hub to the BIS hub. 

• The mean delay values for the OIS intensive sub— networks has decreased. 
This is because one of the ASCs is moved from B_1000 to B_2029 and thus a 
lot of workcell traffic is diverted from B_1000. 

• The randomness in the delay plots for the intensive and non— intensive 
sub— networks has been reduced to a great extent. The traffic between one of 
the ASCs and its workcells has been removed from the FDDI backbone. This 
change reduces the amount of traffic flowing across the backbone, and as a 
result, the plot of the delay curve is smoothed out. 

• By comparing the mean delay and throughput plots with and without the 
BIS network attached, it can be seen that no significant change occurred in 
either the delay or throughput values. Thus it can be said that the BIS 
network has no major effect on the OIS network. 
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4.7 Conclusions 


This chapter explains the ASRM network as of August 10, 1993 and compares the 
results from simulating this new network model with those of the previous model. 
Moving the 73 OIS workstations from the OIS hub to the BIS hub and moving one of 
the ASCs from B_1000 to B_2029 made a positive change in the network performance. 
The mean delay of the OIS intensive sub— networks has decreased. The randomness 
in the delay plots for the intensive and non— intensive networks has been reduced 
giving an indication that the effect of the buffer capacity of the bridges on the network 
has decreased. Also it was observed that the BIS network has no major effect on the 
OIS network. From these changes it can be said that more peer-to-peer 
communication will reduce the heterogeneity of the traffic flow across the network and 
prevent the traffic congestion at different junctions of network. 
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CHAPTER 1.0 


INTRODUCTION 

The Advanced Solid Rocket Motor (ASRM) facility at Yellow Creek 
near Iuka, Mississippi is part of a National Aeronautics and Space 
♦Administration (NASA) program to substantially improve the flight safety, 
reliability, productivity, and performance of the space shuttle’s solid rocket 
motors. The ASRM will be a replacement for the current space shuttle 
Redesigned Solid Rocket Motor (RSRM). 

The facility will be governmentr-owned but contractor— operated. 
Lockheed Missiles and Space Company Inc., (LMSC) is the prime contractor. 
The operation of the facility will be directed by the subcontractor Aerojet 
ASRM division (AAD); RUST International Corporation (RUST) is 
responsible for the engineering and construction of the facility [1]. 

1.1 ASRM System Configuration 

The operations at the ASRM site will be performed in different 
buildings scattered over a large area. These buildings will be 
inter-connected through a Local Area Network (LAN). The buildings can be 
classified as Manufacturing Intensive buildings and Manufacturing 
Non— Intensive buildings, depending on the type of operation performed 
within the building. There will be four Manufacturing Intensive hubs and 
four Manufacturing Non-Intensive hubs connecting the respective buildings 
to the Main Computing Center in Building 1000 (B_1000). All the workcells 
will be connected to the nearest Manufacturing Intensive Hub. 
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Each Manufacturing Intensive hub will communicate with either the 
Operational Information System (OIS) or an Area Supervisory Computer 
(ASC) via a Fiber Distributed Data Interface (FDDI) protocol over an optical 
fiber link. The workstations will interact with the OIS, while the workcell’s 
data will be routed to the ASCs. Each Manufacturing Non-Intensive hub 
will communicate with the Business Information System (BIS) by Ethernet 
protocol over an optical fiber link. 

The two VAX computers in the OIS VAX cluster can communicate 
directly with each other. The BIS on the other hand is a single entity. All 
the printer jobs throughout the campus except those from B_1000 will be 
routed through the Gandalf terminal server by the BIS. 

For all the data transfer, the required routing, security, and flexibility 
will be provided by the Cabletron Multi Media Access Centers (MMACs) 
which will be used throughout the campus. The overall network logically 
forms one large FDDI ring although physically it is a combination of various 
point-to-point connections. 

1.2 Summary of the Forthcoming Chapters 

The main aim of the thesis is to present the overall communication 
network structure for the ASRM facility. The thesis is composed of chapters 
discussing the ASRM communication network structure, the BONeS 
simulation of the ASRM network, and an analysis of the simulation results. 

The chapter on ‘ASRM Communication Network Structure’ 
concentrates on the network connectivity, cabling, and the different 
protocols used. This chapter also explains the flow of data in the network. 
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The chapter on ‘BONeS Modeling’ gives an overview of the BONeS 
simulator. This chapter also describes the different BONeS models 
developed to simulate the ASRM environment and the different probes and 
the iteration settings used. 

The ‘Analysis and Results’ chapter comments on the network 
expectations and the network evaluation parameters. The chapter also 
summarizes the various plots of Mean Delay and Throughput versus Traffic 
Intensity. 

The ‘Conclusion’ chapter at the end of the thesis summarizes the 
different findings from the simulation results. The chapter also makes an 
attempt to validate the simulation model and verify the simulation results. 
A few recommendations for further study is also provided at the end of that 
chapter. 

1.3 Research Objective 

The main objective of the research was to simulate and analyze the 
network to determine its performance under different conditions. 
Comdisco’s Block Oriented Network Simulator (BONeS) was used for 
network simulation. The performance of the network with the given 
topology and protocols can be evaluated using BONeS. The two primary 
evaluation parameters used to judge the network performance were the 
throughput and the delay. The aim of the simulations was to estimate the 
loading of the OIS, the BIS, the ASCs, and the network links due to the 
traffic generated by the workstations and the workcells over the entire site. 



CHAPTER 2.0 

ASRM COMMUNICATION NETWORK STRUCTURE 


2.1 Main Computing Center (Building 1000) 

2.1.1 Purpose of the Main Computing Center 

Building 1000 (B_1000) will provide an efficient means to plan, 
control, and document the manufacturing of solid rocket motors for the 
ASRM project. All the workstations and the workcells communicate only 
with the OIS, the BIS, and the ASCs in B_1000; there is no peer-to— peer 
communication required. B_1000 also provides a link between the business 
functions and the manufacturing functions of the facility. The 
interconnection between the devices in B_1000 is shown in Figure 2.1. 

B_1000 will have a Gandalf terminal server. The Gandalf terminal 
server is a large terminal server with a multitude of RS— 232 to Ethernet 
ports. The Gandalf can support 12 separate Ethernet channels. It will be 
the only terminal server throughout the campus. 
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2.1.2 BIS Network 

^The BIS will be a VAX cluster consisting of one VAX 6310 and two 
VAX 6420 computers. The BIS will be connected to its Cabletron hub by 
thick-wire coaxial with 10BASE5 protocol. The main functions of the BIS 
network will be routing to / from the Gandalf terminal server and serving 
most of the devices inside B_1000. 

The BIS devices includes 32 printers, 25 CAD workstations, and 400 
Macintosh computers connected to the BIS hub by 10BASET; 50 PCs 
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connected to the BIS hub by 10BASET; 31 Engineering workstations on 
10BASE2; and 289 dumb terminals connected via Asynchronous Data 
Interface (ADI) to the Gandalf. The connections of the BIS devices are as 
shown in Figure 2.2. 



Figure 2.2 BIS Hub Connections 
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The BIS hub and the OIS hubs will be connected to provide a path for 
the printer jobs from the Manufacturing Intensive buildings to the Gandalf 
terminal server and subsequently to the printers. Except for this function 
and the traffic from the 73 OIS workstations, all the BIS traffic will be 
independent of the OIS traffic. 

2.1.3 OIS Network 

The OIS will be a VAX cluster consisting of two VAX 6000 computers, 
each with one FDDI adapter. In addition to this OIS VAX cluster, there will 
be two VAX 4000 computers, each with one Ethernet adapter. Each of the 
OIS VAX 6000 computers will be connected to the Cabletron hub by optical 
fiber using the FDDI protocol, while each of the OIS VAX 4000 computers 
will be connected to one of the Cabletron hubs by thick wire coaxial cable 
using the 10BASE5 protocol. 

The main operations of the OIS will be to provide efficient means to 
plan, control, and provide data collection using commercial software 
packages[2] and to download and upload information to each ASC, which 
will serve a group of workcells. 

2.1.4 ASC Network 

** Each of the ASCs will be a VAX 4400 with an Ethernet adapter. The 
ASCs will be connected to the Cabletron hub by thick wire coaxial cable 
using the 10BASE5 protocol. 

The ASC is a real-time device which handles the Application 
Program Interfaces (APIs). The ASC has similar functionality to the OIS. 
The ASC will control and manage a set of workcells. The ASCs will 
communicate with the OIS occasionally with a large block of data, rather 
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than communicating continuously, which would slow down the OIS 
operation. Also if the OIS goes down, the ASC will keep the network alive 
and log the data. 

2.1.5 Cabletron Devices 

The OIS, the BIS, the ASCs, and the Gandalf terminal server in 
B_1000 will be connected to the outside network complex by the Cabletron 
•'Multi Media Access Centers (MMACs), the intelligent hubs. In addition 
B_1000 will have nine more Cabletron hubs distributed in two switch rooms 
(viz. 507 and 638) for the BIS devices in B_1000. The Cabletron hubs 
provide necessary security, routing, and redundancy [24]. 

The Cabletron devices provide network redundancy in two forms. 
The first method is to ensure that all data connections have two back-up 
paths. This method allows critical servers, nodes, or backbone to be 
backed— up with multiple data paths from one or more MMACs. In event of 
a data path failure, back-up paths take over. This feature is useful in 
connecting the manufacturing intensive hubs to B_1000 at the ASRM site. 
The second method of redundancy built into the MMAC is its load sharing / 
redundant power supplies. 

The MMACs chassis are modular, allowing one to hot swap media 
boards and power supplies. This feature reduces the downtime, as units can 
be serviced quickly without special tools. At the ASRM site all the MMAC 
devices will be MMAC-8FNB allowing for connection of up to seven Media 
Interface Modules (MIM). The first slot in the MMAC will be the EMME 
multichannel management / bridge module. The different MIMs used in the 
network at the ASRM are listed in Table 2.1. 
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Table 2.1 Cabletron MIMs used at ASRM 


Name of the 
Card 

TVpe of the 
Card 

EMME 

Ethernet 

Bridge 

FDMMIM 

FDDI to 

Ethernet 

Bridge 

MT8-MIM 

DELNI Card 

FOR- 

MIM-22 

10BASE-FL 

Card 

TPRMIM-36 

10BASE-T 

Card 

CXRMIM 

DEMPR 

Card 

GX-M 

r* 

GatorStar 

Card 

FDMMIM-0 

4 

FDDI 

Concentra- 

tor 


Protocol 


Ethernet 



Ethernet 



Number of 
ports 


4 ports 


8 ports 


8 ports 


12 ports 


24 ports 


12 ports 


24 ports 


FDDI 


4 ports 


Comments 


Used as a 
management 
module in all 
the MMACS 


Connects 10 
Mbps Ether- 
net to 100 
Mbps FDDI 


AUI Trans- 
ceiver 


Provides con- 
nectivity for 
12 Ethernet 
channels 


Provides 
Connectivity 
for 24 Ether- 
net Channels 


Provides 
Connectivity 
for 12 Ether- 
net Channels 


Integrates 24 
port Local- 
Talk repeater 
with a Local- 
Talk to 
Ethernet 
router 


Provides 4 
concentrator 
ports for 
FDDI con- 
nections 
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2.2 Network Cabling at the ASRM Site 
2.2.1 Transmission Media 

The transmission medium is the physical path between transmitter 
and receiver in a data transmission system. The characteristics and quality 
of data transmission are determined both by the nature of the signal and the 
nature of the medium. Table 2.2 gives typical characteristics for guided 
* media, including the total data rate that the medium can support, the 
bandwidth the medium can transmit, and the minimum repeater spacing for 
digital transmission [15]. 


Table 2.2 Transmission Media Characteristics 


Transmission 

Medium 

Total Data 
Rate 

Bandwidth 

Repeater 

Spacing 

Twisted Pair 

4 Mbps 

250 KHz 

2—10 Km 

Coaxial Cable 

500 Mbps 

350 MHz 

1-10 Km 

Optical Fiber 

2000 Mbps 

2000 MHz 

10 - 100 Km 


2.2.2 Outdoor Cabling at the ASRM Site 

All the outdoor cabling will be optical fiber. All optical fiber will be 62.5 
/ 125 micron multimode optical fiber. The outdoor cabling will support the 
FDDI standards for installation methodology and signal loss. There will be 
no oCTtside splicing of the fiber, and all the indoor splicing will be done by 
fusion. 

The manufacturing intensive buildings will have two FDDI data paths 
from B_1000 with automatic switchover. One data path will be buried, while 
the other will be aerial. Buildings 1016, 2029, 2030, and 2031 are the 
manufacturing intensive buildings; each will have a hub directly connected to 
a hub in B_1000. Buildings 2060 and 2076 will be connected to the hub in 
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building 2029. Each hub will receive two pairs of fibers from the outside cable 
plant. All workstations and workcell devices will receive two fibers each from 
the respective hubs. 

All the manufacturing non-intensive buildings in the complex will 
receive two fibers for its hub via the outside cable plant. All the workstations 
inside the buildings will get two fibers each from the respective hub. 

Every FDDI hub will have at least three redundant paths, viz. Channel 
A and Channel B of FDDI and a 10BASE— FL backup. Also every FDDI hub 
will have two redundant dual rings. 

2.2.3 Indoor Cabling at the ASRM Site 

For the indoor cabling in the manufacturing intensive buildings, the 
10BASE-FL protocol will be used, mainly because it allows lower light levels 
and 16 redundant data paths. In addition, the Cabletron devices support the 
10BASE— FL protocol [24]. 

2.2.4 Telephone Cabling 

The telephone system at ASRM Iuka is being built around an Intecom 
S/80 switch. The only overlap in the voice and data networks is between the 
Gandalf terminal server and the RS— 232 devices it serves. The Intecom 
system will be used as the network for communicating serial information 
between the aforementioned devices. The RS— 232 devices consist of printers 
and some workcells. 

2.2.5 Physical Distances 

Table 2.3 gives the physical distance of all the buildings from the 
nearest hub. Table 2.4 gives the physical distance of all the hubs from B_1000. 



Table 2.3 Distances of each building from the nearest hub 


Building 

No. 

Building Name 

No. of 
worksta- 
tions 

No. of 
work- 
cells 

Link 

Near- 

est 

hub 

Dis- 

tance 

from 

hub(ft) 

1000 

Engineering / 
Computer 

73 

00 

— 

1000 

— 

1001 

Security and 
Medical 

03 

00 

Link #4 

1000 

1500 

1010 

Central 

Warehouse 

10 

00 

Link #4 

1000 

600 

1012/ 

2087 

Warehouse ’A’ 

14 

00 

Link #7 

1012 

— 

1016 

Case Prep, and 
Refurbishment 

27 

16 

Link #3 

1016 

— 

1022 

Chemical Storage 

01 

00 

Link #4 

1000 

2600 

1025 

Carpenters Shop 

01 

00 

Link #4 

1000 

2400 

1032 

Office 

03 

00 

Link #5 

2066 

800 

1045 

Training Center 

04 

00 

Link #4 

1000 

1400 

2028 

Tool Clean / 
Core Prep. 

08 

00 

Link #1 

2029 

2600 

2029 

Remote Control 
Room 

12 

01 

Link #1 

2029 

— 

203ft, 

Non Destructive 
Evaluation Facility 

03 

02 

Link #6 

2030 

— 

2031 

Final Assembly 

15 

00 

Link #2 

2031 

— 

2042 

Main Motor 
Storage 

04 

00 

Link #6 

2030 

8650 
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Table 2.3 (continued) 


Building 

No. 

Building Name 

No. of 
worksta- 
tions 

No. of 
work- 
cells 

Link 

Near- 

est 

hub 

Dis- 

tance 

from 

hub(ft) 

2070 

Sample 

Preparation 

01 

00 

Link #5 

2066 

1450 

2060 

Small Scale 
Propellant Proc. 

04 

02 

Link #1 

2029 

2250 

2066 

Quality Assurance 
Lab. 

05 

00 

Link #5 

2066 

— 

2076 

Qualification 
Motor Facility 

04 

01 

Link #1 

2029 

2550 

2082 

HTPB Storage 
Tank Farm 

01 

00 

Link #1 

2029 

850 

3003 

Deload — Open 
area (no building) 

00 

01 

Link #6 

2030 

7050 

3005 

Control Building 

03 

01 

Link #6 

2030 

5950 

3010 

Incinerator 
System Building 

00 

01 

Link #6 

2030 

4950 

3011 

Feed Prep. 
Facility 

01 

01 

Link #6 

2030 

6600 

4001 

Shipping Dock 

01 

00 

Link #6 

2030 

9700 



TOTAL 

184 

26 




































Table 2.4 Distances of each hub from Building 1000 


Link 

Distance 

(feet) 

Number of 
workstations 
on the link 

Number of 
workcells 
on the link 

Type of the 
link 

Link # 1 : 
(2029) 

6700 

29 

04 

Intensive and 
N on— Intensive 

Link # 2 : 
(2031) 

4650 

15 

00 

Intensive 

Link # 3 : 
(1016) 

1450 

27 

16 

Intensive 

Link # 4 : 
(1000) 

00 

(19+73) + 
BIS devices 

00 

Non— Intensive 

Link # 5 : 
(2066) 

3550 

09 

00 

Non— Intensive 

Link # 6 : 
(2030) 

5000 

12 

06 

Intensive and 
Non— Intensive 

Link # 7 : 
(1012) 

950 

14 

00 

Non— Intensive 




L5 



TotalOIS 

Nodes 

= 1 84 w/s 26 w/c 


4 Intensive Links and 

5 Non— intensive Linki 



14BISw/s 


LINK # 6 

(Intensive and 
. Non— intensive) 


LINK # 5 I 

(Non— intensive! 


1032 

“1 


2070 

-i 


2066 




LINK # 1 
(Non-intensive) 



LINK# 1 
[Intensive and 
Non— intensive) 


LINK #4 
(Non-intensive 


H 

1001 


H 

1010 


H 

1022 



1025 


— 

1045 


LINK # 3 
Vlntensive) 


LINK # 2 
(Intensive) 



Figure 2.3 Building-to-Building External Connections 
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2.3 Protocols used at the ASRM Site 


2.3.1 Standard Protocols 


For two entities to successfully communicate over a network, they 
must conform to some mutually acceptable set of coventions referred to as a 
protocol. A protocol may be defined as a set of rules governing the exchange 
of data between two entities. The Institute of Electrical and Electronic 
Engineers (IEEE) has established different committees to develop standards 
for LANs viz. 802.2 Logical Link Control (LLC), 802.3 Carrier Sense 
Multiple Access Collision Detect (CSMA/CD), 802.4 Token Bus, and 802.5 
Token Ring. The American National Standards Institute (ANSI) has 
developed a specification for LANs using optical fiber. The standard is 
called Fiber Distributed Data Interface (FDDI) and was written by ANSI 


committee X3T9.5 [15]. 


2,3.2 Protocols used at the ASRM Site 

For the data communication network at the ASRM site, two protocols 
are specified: FDDI and CSMA/CD. All the manufacturing intensive 
buildings are connected to B_1000 by links with FDDI protocol, and ah the 
manufacturing non— intensive buildings are connected to B_1000 by finks 
witlrlOBASE-FL protocol (i.e. CSMA/CD on optical fiber). The protocol 
inside both the manufacturing intensive and non-intensive buildings is 
10BASE-FL. In B_1000 the 25 CAD workstations, 400 Macintosh 
computers, and 50 PCs use 10BASET, the 31 Engineering workstations use 
10BASE2, and the 289 dumb terminals use RS-232. The 289 dumb 
terminal traffic is carried over intecom S-80 switch and hence they can be 
considered part of the telephone network. 
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2.3.3 FDDI Protocol 

The FDDI protocol operates on an optical fiber channel at 100 Mbps. Up 
to 1000 nodes can be placed on one optical fiber ring. The nodes can be spaced 
as far as 2 km apart and the ring circumference can be up to 200 km [14]. FDDI 
specifies a topology in which two independent, counterrotating optical fiber 
rings provide a overall bit rate of 200 Mbps, with each channel operating at 
100 Mbps. 

In Figure 2.4 some devices (A type) are attached to both inner and outer 
rings, while other devices (B type) are attached to only one ring. This allows 
a user to designate those critical stations which need additional back-up and 
higher speeds as type A stations. The other, less important ones such as 
isolated workstations or low-priority terminals, can be attached as type B 
stations, at a lesser cost. 



B2 A2 


7 * 

Figure 2.4 FDDI Topology 

The Ring Wiring Concentrator (RWC) acts as a reconfiguration and 
concentration point for all optic wiring and data traffic. The connectors into 
the terminals and wiring concentrator are laser diodes which can drive the 
fiber at a rate of over 100 MHz. FDDI stipulates a standard optic light wave 
of 850 nanometers. 





18 


FDDI utilizes a 4B / 5B encoded signal at a rate of 125 Mbps. Encoded 
signals are grouped as data and linestates. Data signals contain a nibble 
(4—bits) of data encoded into a 5 bit symbol, hence the resulting data rate is 
4 / 5 of the actual bit rate or 100 Mbps. Linestate signals are non— data 5 bit 
symbols that allow for a rudimentary communication protocol below the 
Medium Access Control (MAC) layer. 

FDDI uses a multiple token passing protocol. The token circles the ring 
behind the last transmitted packet from a device. Any station wishing to 
transmit data seizes the token, removes the token, places the packet or 
packets on the ring, and then issues the new token directly behind the data 
stream. 

2.3.4 CSMA/CD Protocol 

CSMA / CD also referred to as Listen While Talk (LWT) is the most 
commonly used Medium Access Control (MAC) technique for bus / tree 
topologies. The original baseband version of this technique was developed and 
patented by XEROX. 

In CSMA / CD many different stations are connected to a common bus. 
If two stations try to transmit at the same time then the packets will collide, 
at which point each station stops transmission and waits a random amount 
of tiffTe before trying to transmit again. If the packet from a station collides 
again, then the station waits a longer amount of time, determined by the 
random exponential backoff time for that station, before trying to transmit. 
The IEEE 802.3 CSMA / CD standard sends data in variable size frames 
commonly called packets with a minimum spacing of 9.6 microseconds. 

For any hub, if there is activity (signal) on more than one input, a 
collision is assumed. A special signal called the collision presence signal is 
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generated. This signal is generated and sent out as long as activity is still 
sensed on any of the input lines after a collision is detected. This signal is 
interpreted by every node as an occurrence of collision. 

2.3.5 ASC to LSC Communication Protocol 

The ASCs will be used to monitor and control the shop floor test 
equipment and the automated workcells. 

OIS ASC 



At the Local Supervisory Computer (LSC) level, data from the workcell 
devices are collected by utilizing software provided by RUST International. 
Data collected at the LSC is transferred to the ASC by a combination of 
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BASEstar request/response transactions and LSC initiated File Transfer 
Protocol (FTP). After the data has been successfully transferred to the ASC, 
the ASC will process the data and pass it to the Work Stream (WS) product on 
the OIS system. After reaching the OIS, the data is made available for 
analysis and manipulation by other software. For more details of the ASC to 
LSC communication please refer to [4]. 

' 2.3.6 FDDI Dual Ring of Treesflll 

A typical FDDI network consists of the following four types of nodes : 
Dual Attached Stations (DAS), Dual Attached Concentrators (DAC), Single 
Attached Stations (SAS), and Single Attached Concentrators (SAC). 



DAS Dual Attached Stations 
SAC Single Attached Concentrator 
SAS Single Attached Station 


Figure 2.6 FDDI Dual Ring of Trees 
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A preferred FDDI topology consists of a dual ring of trees. The trunk 
ring is formed with dual attached stations and concentrators. The trees are 
formed from concentrator connections to SAS and SAC. Typically the dual 
ring itself would consists of concentrators, bridges, routers, file servers, main 
frame computers, etc. Workstations and other desktop computers would be 
connected through concentrators to form trees. 

The use of concentrators to form tree structures offers a number of 
advantages. It allows lower cost SASs to be connected to the ring. It enhances 
network reliability since a concentrator automatically reconfigures the 
network as stations are inserted or deleted from the tree. It also rejects links 
that are faulty and ensures that they do not bring down the ring. A 
concentrator also allows the use of a star wiring topology. 

2.3.7 One Logical FDDI Ring at the ASRM Site 

A simplified figure of the network structure at the ASRM is shown in 
Figure 2.7. Comparing Figures 2.6 and 2.7 shows that logically a dual ring of 
trees exists at the ASRM site. Although physically it is a point-to-point 
connection, the overall network structure will have one logical FDDI ring 
acting as a backbone for the whole complex. 

2.4 Data Rates for the Workstations and the Workcells 

2.4.1 Data Rate for the Workstations 

The data rate for the workstations can be computed by assuming that 
the workstation will be sending a block of data such as a text or graphics 
screen. A page of graphics was assumed to be 640 pixels by 480 lines with 
16 colors (4 bits). This is equal to 1.2288 Mbits (640 x 480 x 4) which is equal 
to 153.6 kilobytes of data to be transmitted. The number of packets required 
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Figure 2.7 FDDI Ring at the ASRM Site 


to send 153.6 kilobytes was calculated using 750 byte (6000 bit) packets. 
The delay per graphics page was calculated by multiplying the number of 
packets by the delay per packet obtained for 10 sec simulation run. 

2.4.2 Data Rate for the Workcells 

The data rates for the workcells were obtained from RUST [3] and are 
tabulated in Table 2.5 below. 
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Table 2.5 Workcells and their data rates 















Work- 

cell 

ID# 

Description 

Work- 

cell 

type 

Data 

Rates 

Dura- 

tion 

W 102 

Robotic washout station 

MFG 

441.6 by- 
te s/eec 

24 hrs 

W 104a 

Hydrotest equipment 

Test- 

ing 

441.6 by- 
tes/sec 

6 times/ 
month 

W 104b 

Hydrotest data acquisition 
system 

Test- 

ing 

441.6 by- 
te s/sec 

6 times/ 
month 

W 107 

Electromag-acoustic eddy 
current test 

NDE 

533 bytes/ 
day 

16hrs / 
3 days 

W 114 

Robotic dimensional 
inspection 

NDE 

1.44 

Mbytes 

/day 

12 hrs/ 
! 3 days 

W 116 

Aqueous degreaser 

MFG 

384 bytes/ 
sec 

8 hrs 

W 117 

Robot clean/paint/osee 

MFG 

364.8 by- 
tes/sec 

40 hrs/ 
5 days 

W 118 

Plastic media blast robot 

MFG 

105.6 by- 
te s/sec 

16 hrs/ 
5 days 

W 121 

Clean, dry, liner robot 

MFG 

604.8 by- 
te s/sec 

16 hrs/ 
day 

W 148 

Horizontal elastic insulation 
application 

MFG 

268.8 by- 
te a^sec 

60 hrs/ 
5 days 

W 149 

Pattern cutting station 

MFG 

720 bytes/ 
sec 

4 hrs/ 
day 

W 159 

Aqueous degreaser 

MFG 

384 bytes/ 
sec 

8 hrs 

W 160 

Plastic media blast robot 

MFG 

652.8 by- 
te s/sec 

8 hrs/ 5 
days 

W 161 

Component Washout Robot 

MFG 

182.4 by- 
te s/sec 

8 hrs/ 5 
days 

W 168 

Ultrasonic inspection 

NDE 

533 bytes/ 
day 

16 hrs/ 
3 days 

W 169 

Autoclave (insulation curing) 

MFG 

86.4 by- 
te s/sec 

40 hrs/ 
5 days 

DCS 

Mix/Cast distributed control 
system 

MFG 

960 bytes/ 
sec 

96 hrs/ 
month 

W 402 

Real time radiography 

NDE 

800 bytes/ 
hr 

40 hrs/ 
3 days 
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Table 2.5 (continued) 


Bldg 

No. 

Work- 

cell 

ID# 

Description 

Work- 

cell 

Type 

Data 

Rates 

Dura- 

tion 


W 403 

Ultrasonic test 

NDE 

800 bytes/ 
hr 

24 hrs/ 
3 days 

B_2060 

WSSP 

Small scale propellant 

MFG 

768 bytes/ 
sec 

const- 

ant 



Scales 

MFG 

18816 by- 
tes / day 

const- 

ant 

B_2076 

MTRQ 

Motor qualification data 
acquisition system 

Test- 

ing 

576 

Kbytes/ 

sec 

6 times/ 
month 

B_3003 


Propellant removal station 

MFG 

441.6 by- 
te s/sec 

24 hrs 

B_3005 


Thermal treatment control 

MFG 

384 bytes/ 
sec 

8 hrs 

B_3011 


Feeder preparation 

MFG 

384 bytes/ 
sec 

8 hrs 

B_3010 


Incinerator 

MFG 

384 bytes/ 
sec 

8 hrs 


2.5 Data Flow over the Network 


2.5.1 Data Flow for the Manufacturing Intensive Buildings 

There is an FDDI data path between the manufacturing intensive 
buildings and B_1000. Buildings 1016, 2029, 2030, and 2031 are the 
manufacturing intensive buildings, and each will have a hub directly 
connected to an OIS hub in B_1000. The workstations in these buildings will 
be communicating with the OIS 6000 computers. The workcells in these 
buildings will communicate via the OIS hub with the two ASCs. 
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2.5.2 Data Flow for the Manufacturing Non— Intensive Buildings 

There is a 10BASEFL data path between B_1000 and the 
manufacturing non-intensive buildings 1001, 1002, 1010, 1025, and 1045. All 
other manufacturing non-intensive buildings will be connected to B_1000 
through the nearest manufacturing non-intensive hub in buildings 2029, 
2066, and 2030. The workstations in all the manufacturing non-intensive 
buildings will communicate via the BIS hub with the two OIS 4000 computers. 



CHAPTER 3.0 


BONeS MODELING 


3.1 Network Simulation 

3.1.1 Different methods of Network Modeling [161 

Network modeling can be done by several different means, each 
having its advantages and disadvantages. The first method is by developing 
a mathematical model of the network, normally using queueing theory. This 
model can then be used to provide data about the performance of the 
network. Due to the simplifying assumptions required to use this type of 
modeling, it is often not the best possible model and frequently is not 
feasible. 

The second approach to analyze the performance of a network is to 
actually build the network. Although this approach provides very good 
results, it is normally very expensive, both in time and resources. 

The third approach is that of computer simulation. Using a computer 
simulation the user can model the network to as close to reality as desired. 

This approach is less expensive than building the network. The major 
disadvantage of this approach is insuring that the simulation model 
accurately models the intended network. 
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3.1.2 BONeS Simulator f201 

The Block Oriented Network Simulator (BONeS) provides an 
interactive graphical environment for simulation-based analysis and design 
of a broad range of communication networks. The integrated BONeS 
environment includes the capability to : 


1. Graphically describe data structures in a hierarchical 
fashion. 

2. Graphically describe protocol functions, node processing, and 
network topology in a hierarchical fashion using block 
diagrams. 

3. Translate the network model into a C program, and execute 
an event driven simulation of the model. 

4. Perform design iterations and tradeoff analysis. 

5. Document both models and results. 


BONeS provides an easy-to-use modeling and simulation 
environment, an excellent model library that is user extensible, and a set of 
powerful analysis tools. BONeS minimizes the amount of code the user has 
to write and provides on-line help, documentation aids, and error checking. 
These features free the user from the low level details of simulation 


programming and directs the focus on modeling, analysis, and design. 

In the BONeS environment, the network model is specified in terms of 
the network topology, traffic, packet and message (data) structures, and 
protocol functions. The user constructs the network graphically and 
hierarchically using the building blocks from the BONeS model library. 



Simulation model design consists of three elements : data structures, 
modules, and a system. The modules in BONeS control the flow of the data 
structures. Many basic modules are provided with BONeS, such as decision 
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nodes, random traffic generators, and fixed delays. These can be combined to 
form new modules to meet the specific needs of the simulation [20]. 

BONeS is an event driven simulation. All events except traffic 
generators are triggered by a previous event called a Trigger. If a block is not 
triggered then there will be no output. Thus when building a model using the 
provided blocks, race conditions such as parallel inputs must be avoided. 
Instead, blocks should be cascaded to prevent race conditions. 

The different nodes that are constructed in this simulation are 
workstation and workcells. Models of other nodes, such as CSMA/ CD nodes, 
FDDI nodes, and bridges are included in the BONeS library. 

3.2.1 CSMA/CD Workstation Model 

BONeS comes with a complete model for a CSMA/CD workstation 
which includes the carrier sense, collision detection, exponential backoff, 
attempt limit, slot time, and the interframe gap. For a worst case analysis the 
packet size will be 64 bytes. If the packet size is small the transmission time 
will be small with respect to the propagation delay, and more collisions will 
occur [17]. The parameters of the CSMA / CD nodes are set to the IEEE 802.3 
CSMA / CD standard and are listed below : 

• Backoff limit = 10 
** • Attempt limit = 16 

• Slot time = 5.12 x 10 -5 seconds 

• Interframe gap = 96 bits 

• Transmission speed = 1 x 10 -7 bits per second 

3.2.2 FDDI Backbone Model 

The parameters of the FDDI backbone model for the ASRM network 
were set similar to the FDDI backbone model of the campus— wide network 



29 


example included in the version 2.0 of BONeS[20]. The parameters are listed 
below : 

• Capacity = 100 Mbps 

• Target Taken Rotation Time = 0.01 seconds 

• Operational Target Rotation Time = 0.01 seconds 

• Propogation Delay (FDDI) = 1.0 x 10 -5 seconds 

• Ring Latency = 6.006 x 10 -5 seconds 

• Synchronous Allocation = 0.0 seconds 

• Synchronous Buffer Size = 0 

• Asynchronous Buffer Size = 2000 elements 

3.2.3 Cabletron MIM Model 

A MIM is an add-on card that can be plugged into a slot of a MMAC. 
Each MIM has ports on its faceplate to support cabling. Each MIM functions 
uniquely as a repeater or as a bridge. The model of the repeater MIM passes 
all frames that are received on the receive port to all transmitting ports with 
delay. The delay information for each MIM was obtained from [24], Table 3.1 
gives the list of BONeS modules used for each MIMs at the ASRM site. 

Table 3.1 BONeS Modules for the MIMs 


Name of the MIMs 
at the ASRM site 

Type of the device 

BONeS Module that 
are used 

Cabletron EMME card 

Ethernet bridge 

CSMA / CD Bridge 

Cabletron FDMMIM 

FDDI to Ethernet 
bridge 

FDDI to CSMA / CD 
Bridge 

Cabletron MT8-MIM 

DELNI card 

Fixed Delay 

Cabletron FORMIM 

10BASE— FL card 

CSMA /CD hub 

Cabletron TPRMIM 

10BASE-T card 

CSMA / CD hub 

Cabletron CXRMIM 

DEMPR card 

CSMA / CD hub 

Cabletron GX-M 

GatorStar card 

LocalTalk to CSMA / 
CD router. 

Cabletron FDMIM-04 

FDDI concentrator 

FDDI hub 




3.2.4 Traffic Source Model 


A traffic source model was developed to model a workstation sending 
a block of data such as a text or graphics screen. The traffic source model sends 
a set number of packets at an interarrival rate set by the user. The interarrival 
rate was modeled with a Poisson distribution because traffic on a LAN tends 
to have a Poisson distribution [18]. 

f 3.3 BONeS Modules for ASRM Sub-networks 

The different BONeS modules developed for this simulation are as 


shown in Table 3.2 



Table 3.2 BONeS Modules for ASRM Sub— networks 
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BONeS Module 

(indicated in upper 
left on each figure) 

MMACto 
which the module 

is connected 

Devices in this 
module 

Destination 

ASRM Network 




MAC— N etwork 

MMAC in Switch 
Rm 210 in B_1000 

80 MAC w/s 

3 modules to 
BIS 6310 and 
2 modules to 
BIS 6420_A 

B_2087_NI 

Non— Intensive 
MMAC in B_1012 

14 MAC w/s in 
B_1012 

BIS 6420_A 

RM 507 

MMAC in Comp 
Rm 507 in B_1000 

50 PCs, 7 SGIs 
with a server 

BIS 6420_B 

Printer-CAD- 

ENG 

MMAC in Switch 
Rm 210 in B_1000 

25 CAD w/s with 
5 servers, 31 
ENG with 9 serv- 
ers and 32 MAC 
printers 

BIS 6420J3 

RM 63 8 A 

MMAC in Switch 
Rm 638 in B_1000 

80 MAC w/s 

BIS 6420_B 

B_2029_NI 

Non-Intensive 
MMAC in B_2029 

8 w/s in B_2028 
1 w/s in B_2082 

OIS 4000_A 

B_2030_NI 

Non-Intensive 
MMAC in B_2030 

4 w/s in B_2042 
3 w/s in B_3005 
1 w/s in B_3011 
1 w/s in B_4001 

OIS 4000_A 

B_2066_NI | 

Non— Intensive 
MMAC in B_2066 

3 w/s in B_1032 
1 w/s in B_2070 

OIS 4000_A 

RM 638B 

MMAC in Switch 
Rm 638 in B_1000 

Gandalf 
Terminal server 

OIS 4000_A 

ois- 

Workstations 

MMAC in BIS Hub 
in B_1000 

73 OIS MAC w/s 

OIS 4000_B 

B_1001_NI 

MMAC in BIS Hub 
in B_1000 

3 w/s in B_1001 

OIS 4000_A 

B_1045_NI 

MMAC in BIS Hub 
in B_1000 

4 w/s in B_1045 

OIS 4000_A 




Table 3.2 (continued) 
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BONeS Module 

(indicated in upper 
left on each figure) 

MMACto 
which the module 
is connected 

Devices in this 
module 

Destination 

B_1010_NI 

MMAC in BIS Hub 
in B_1000 

10 w/s in B_1010 

OIS 4000_A 

B_1002_NI 

MMAC in BIS Hub 
in B_1000 

1 w/s in B_1002 

OIS 4000_A 

B_1025_NI 

MMAC in BIS Hub 
in B_1000 

1 w/s in B_1025 

OIS 4000_A 

B_1016_I 

Intensive 
MMAC in B_1016 

27 w/s in B_1016 
16 w/c in B_1016 

OIS 6000 A 
ASC_A 

B_2029_I 

Intensive 
MMAC in B_2029 

12 w/s in B_2029 

1 w/c in B_2029 
4 w/s in B_2060 

2 w/c in B_2060 
4 w/s in B_2076 
1 w/c in B_2076 

OIS 6000 B 
ASC_B 

B_2030_I 

Intensive 
MMAC in B_2030 

3 w/s in B_2030 
2 w/c in B_2030 
1 w/c in B_3003 
1 w/c in B_3005 
1 w/c in B_3010 
1 w/c in B_3011 

OIS 6000 B 
ASCJB 

B_2031_I 

Intensive 
MMAC in B_2031 

15 w/s in B_2031 

OIS 6000_A 


All the modules created for the ASRM network are shown in Appendix 

Al. ^ 

3.4 Probes and the Iterations Setting 

Several probes were placed throughout the network to gather statistics 
during the simulation. The mean delay per packet, received throughput, 
transmitted throughput, and the number of completed packets were collected- 
for each separate link. Each iteration interval was divided into ten batches 
in order to collect these statistics. 
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3.4.1 Delay and Throughput Measuring Probes 

These statistics were collected by placing a Generic Probe on the Media 
Access Control (MAC) Statistics module in each link. The MAC Statistics 
module was used to measure the delay and throughput for all CSMA/CD 
workstation models on one link. All CSMA/CD workstation model MAC 
instances share the same memory. Therefore, all the CSMA/CD workstation 
^models write the delay and throughput into one memory. These statistics are 
then made available to the Post Processor in BONeS by placing a Generic 
Probe on the MAC Statistics Compute module. 

3.4.2 Iteration Settings 

The traffic intensity per node was varied from 10 Kbps to 90 Kbps at 
twelve points during the simulation. The traffic intensity was varied with an 
exponential function to show the knees of the curves. Different simulation 
runs were made by setting the simulation time per iteration to one, two, and 
ten seconds. The actual computer time to simulate and record one second of 
actual network operation was approximately 30 hours on a 
moderately— loaded Sun 600/MP with 128 Megabytes of memory. 



CHAPTER 4.0 
ANALYSIS AND RESULTS 


4.1 Network Expectations 

The network should be reliable and have redundant links since the 
control of the manufacturing will be accomplished over the LAN. Large 
amounts of data will be required due to the extensive monitoring and docu- 
mentation required for the manufacture of the solid rocket motors in the 
Space Shuttle program [2]. 

4.2 Network Evaluation Parameters 

The two primary evaluation parameters used to judge the network 
performance are throughput and delay. The throughput is the effective bit 
rate of the system in bits per second (bps). It does not include the overhead 
bits used by the protocol or the packets that have to be re— transmitted. The 
delay in a LAN is determined by the mean delay per packet [15]. 

The delay in a LAN is mostly caused by the following three factors: 
the propagation delay, the delay in a transceiver, and the queuing delay in a 
bridge. Also the user response time is important. These delays are modeled 
using several different techniques in the simulation. 
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4.2.1 Propagation Delay 

The propagation delay of the light signal traveling down the fiber is 
modeled by using a fixed delay model provided by BONeS. The link delay is 
calculated by dividing the distance by the speed at which the light travels 
down the fiber (0.67 times the speed of light) [2], 

4.2.2 Delay in a Transcevier 

The worst case collision detection time of a particular CSMA/CD 
commercial transceiver was found to be 900 nanoseconds [21]. The worst 
case packet delay of a particular commercial optical hub was found to be 630 
nanoseconds [21], This delay is caused by the optical-to— electrical and 
electrical-to— optical conversion. These delays are also modeled by a fixed 
delay in the simulation [2], 

4.2.3 Queue Delay in a Bridge 

In the simulation model each of the CSMA/CD networks is connected 
to the FDDI backbone by a bridge. A bridge converts the CSMA/CD packet 
to an FDDI packet and buffers the incoming packets until they are serviced. 

If a packet enters the bridge and the queue is full, the packet is discarded. If 
the queue is large but not full, then the packet will be delayed. 

*^V 

4.3 Mean Delay and Throughput Plots 

The statistics collected with the probes during the simulation are 
plotted to judge the performance of the network. Different simulation runs 
were made by setting the simulation time per iteration to one, two, and ten 
seconds. The mean delay per packet and throughput are plotted versus the 
offered traffic intensity. These plots are created using the Post Processor in 
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BONeS and show the performance of the network at each iteration of the 
traffic intensity during the simulation. 

4.3.1 BIS Devices Mean Delay Plots 

The mean delay per packet versus the offered traffic intensity plots 
are shown in figures 4.1, 4.2, and 4.3. The BIS devices delay plot shows a 
rising curve. 

In the case of the BIS devices plot, the mean delay per packet 
increases as the offered traffic intensity increases. The delay curves level 
out close to a traffic intensity of 40 Kbps per node and then start to climb 
linearly. This agrees with the generally accepted assumption that a 
CSMA/CD network overloads at somewhere between 30% and 50% of its 
maximum transmission speed [15]. Note that the transmission speed of a 
link (10 Mbps for Ethernet) equals the traffic intensity per node times the 
number of nodes. There are approximately 80 nodes per link in the BIS 
section; 80 nodes transmitting at 40 Kbps is 3.2 Mbps. The simulation only 
calculates delays per packet for successful packet transmissions and does 
not include lost packets. 

4.3.2 BIS Devices Throughput Plots 

^The throughput versus the offered traffic intensity plots are shown in 
figures 4.4, 4.5, and 4.6. The BIS devices throughput plot shows a rising 
curve. 

The curves in these figures show that the throughput increases 
linearly with the offered traffic intensity per node. When multiple subnets 
saturate, the actual amount of traffic injected into the network is limited. 
So, the throughput of larger networks increases at a slower rate at higher 
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traffic intensity per node. The analysis of the mean delay per packet shows 
that the delay curve levels out close to a traffic intensity of 40 Kbps per 
node. So the throughput for each of the links should be determined at the 
traffic intensity of 40 Kbps per node. 

Table 4.1. Delay per packet and throughput for the BIS devices 


Link 

No of 
nodes 

Mean delay/packet at traf- 
fic intensity of 40 kbps in 
msec 

Throughput at traffic in- 
tensity of 40 kbps in Mbps. 

1 sec 

2 sec 

10 sec 

1 sec 

2 sec 

10 sec 

MAC Network 

80 

3.0 

2.5 

3.0 

3.4 

3.3 

3.2 

Printer Network 

56 

1.0 

1.0 

1.0 

2.4 

2.4 

2.4 

B_2087_NI 

14 

2.0 

2.0 

2.2 

0.6 

0.6 

0.6 

RM 507 

57 

2.0 

2.0 

2.2 

2.5 

2.4 

2.4 

RM 63 8 A 

80 

3.0 

2.8 

2.6 

3.4 

3.2 

3.2 


4.3.3 Non-Intensive Network Delay Plots 

The mean delay per packet versus the offered traffic intensity plots 
are shown in figures 4.7, 4.8, and 4.9. The Non— Intensive network delay 
plot shows a knee curve. 

In the case of the Non-Intensive network, all the links show a knee at 
a particular traffic intensity. The mean delay per packet decreases beyond 
this traffic intensity, because the number of completed packets decreases 
beyond the knee of each link. Since there is more traffic to be transmitted 
than the network can handle, packets waiting to be transmitted are queued 
within the bridge. As the incoming traffic rate is higher than the packet 
service rate, the queue size grows. At high loads the queue size will grow 
steadily until the buffer is filled to capacity. Any subsequent incoming 
packets to the queue will be dropped. The packets that do get through have 
a smaller delay because the mean delays are only calculated for successful 
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transmissions of the packets in the simulation. This shows that the links 
are overloaded and only a few nodes can communicate. All other nodes are 
locked out by the excessive traffic. 

The zero values for delay per packet for certain sub-networks 
indicates that no node in that particular sub-network was able to do any 
successful transmission of the packets in the specified simulation time run. 

The random nature of the delay plot obtained for a 10 sec simulation 
can be attributed to the heterogeneity of the network and the traffic flow. 

4.3.4 Non— Intensive Network Throughput Plots 

The throughput versus the offered traffic intensity plots are shown in 
figures 4.10, 4.11, and 4.12. The Non— Intensive network throughput plot 
shows a rising curve. 

The curves in these figures show that the throughput increases 
linearly with the offered traffic intensity per node. However the analysis of 
the mean delay per packet shows that the links are overloaded beyond a 
certain traffic intensity. This is because only a few nodes are able to 
transmit and all others cannot. The throughput beyond this knee is only 
available to a few nodes. So the throughput for each of the links should be 
determined at the traffic intensity where the maximum delay per packet 
occurred. 
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Table 4.2. Delay per packet and throughput for the Non-Intensive network 


Link 

No 

of 

nodes 

Maximum delay/ 
packet (msec) 

Traffic intensity at 
maximum delay/ 
packet (kbps) 

Throughput at maxi- 
mum delay per 
packet (Mbps) 

1 sec 

2 sec 

10 

sec 

1 sec 

2 sec 

10 

sec 

1 sec 

2 sec 

10 

sec 

B_1001_NI 

3 

0.0 

0.0 

32.0 

40 

40 

55 

0.12 

0.12 

0.12 

B_1045_NI 

4 

0.0 

0.0 

40.0 

40 

40 

55 

0.16 

0.16 

0.16 

B_1010_NI 

10 

23.0 

23.0 

86.0 

40 

40 

15 

0.52 

0.42 

0.18 

B_2066_NI 

4 

0.0 

0.0 

83.0 

40 

40 

15 

0.34 

0.34 

0.14 

RM 638B 

1 

0.0 

0.0 

10.0 

40 

40 

75 

0.82 

0.72 

0.72 

B_1002_NI 

1 

0.0 

0.0 

14.0 

40 

40 

75 

0.04 

0.04 

0.04 

B_2029_NI 

9 

23.0 

23.0 

83.0 

40 

40 

15 

0.44 

0.42 

0.18 

B_2030_NI 

9 

23.0 

23.0 

83.0 

40 

40 

15 

0.48 

0.42 

0.18 

B_1025_NI 

1 

0.0 

0.0 

83.0 

40 

40 

15 

0.04 

0.04 

0.02 


4.3.5 Intensive Network Delay Plots 

The mean delay per packet versus the offered traffic intensity plots 
are shown in figures 4.13, 4.14, and 4.15. The Intensive network delay plot 
shows a knee curve. 

In the case of the Intensive network, all the links show a knee at a 
particular traffic intensity. The mean delay per packet decreases beyond 
this traffic intensity, because the number of completed packets decreases 
beyond the knee of each link. Even though the traffic intensity is being 
increased, many nodes are not given access to the channel. The packets that 
do get through have a smaller delay because the mean delays are only 
calculated for successful transmissions of the packets in the simulation. 
This shows that the links are overloaded and only a few nodes can 
communicate. All other nodes are locked out by the excessive traffic. 
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4.3.6 Intensive Network Throughput Plots 

The throughput versus the offered traffic intensity plots are shown in 
figures 4.16, 4.17, and 4.18. The Intensive network throughput plot shows a 
rising curve. 

The curves in these figures show that the throughput increases 
linearly with the offered traffic intensity per node. But the analysis of the 
mean delay per packet shows that the links are overload beyond a certain 
traffic intensity. This is because only a few nodes are able to transmit and 
all others cannot. The throughput beyond this knee is only available to a 
few nodes. So the throughput for each of the links should be determined at 
the traffic intensity where the maximum delay per packet occurred. 

The throughput plot for building 2029 intensive (B_2029_I) shows a 
very high value as compared to the throughput plots of other intensive 
buildings. This is because of the workcell MRTQ connected to it has a data 
rate of 4.608 Mbps [3]. 


Table 4.3. Delay per packet and throughput for the Intensive network 


Link 

: No 
of 

nodes 

Maximum delay/ 
packet (msec) 

Traffic intensity at 
maximum delay/ 
packet (kbps) 

Throughput at maxi- 
mum delay per 
packet (Mbps) 

1 sec 

2 sec 

10 

sec 

1 sec 

2 sec 

10 

sec 

1 sec 

2 sec 

10 

sec 

B_2031_I 

15 

3.0 

3.4 

9.0 

65 

25 

20 

1.0 

0.4 

0.3 

B_2029_I 

24 

1.5 

1.5 

13.0 

40 

40 

20 

5.1 

5.0 

4.6 

B_1016_I 

43 

4.0 

5.2 

17.0 

65 

25 

20 

2.4 

0.7 

0.7 

B_2030_I 

9 

1.0 

1.5 

16.0 

40 

40 

20 

0.3 

0.3 

0.1 
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4.4 Delay per Graphics Pape 

A page of graphics was assumed to be 640 pixels by 480 lines with 16 
colors (4 bits). This is equal to 1.2288 Mbits (640 x 480 x 4) which is equal to 
153.6 kilobytes of data to be transmitted. The number of packets required to 
send 153.6 kilobytes using 750 byte (6000 bit) packets will be 205 packets. 
The delay per graphics page was calculated by multiplying the number of 
packets by the delay per packet obtained for 10 sec simulation run. The 
results are summarized in Table 4.4, 4.5, and 4.6. 

Table 4.4 Delay per Graphics page for the BIS devices 


Link 

Mean delay/packet (msec) 
for 10 sec simulation 

Delay per Graphics page 
(msec) 

MAC Network 

3.0 

615 

Printer Network 

1.0 

205 

B_2087_NI 

2.2 

451 

RM 507 

2.2 

451 

RM 638A 

2.6 

533 


Table 4.5 Delay per Graphics page for the Non— Intensive network 


Link 

Maximum delay/packet 
(msec) for 10 sec simulation 

Delay per Graphics page 
(msec) 

B_1001_NI 

32 

6560 

B_1045_NI 

40 

8200 

B_1010_NI 

86 

17630 

B_2(f66_NI 

83 

17015 

RM 638B 

10 

2050 

B_1002_NI 

14 

2870 

B_2029_NI 

83 

17015 

B_2030_NI 

83 

17015 

B_1025_NI 

83 

17015 




Table 4.6 Delay per Graphics page for the Intensive network 


Link 

Maximum delay/packet 
(msec) for 10 sec simulation 

Delay per Graphics page 
(msec) 

B_2031_I 

9 

1845 

B_2029_I 

13 

2665 

B_1016_I 

17 

3485 

B_2030_I 

16 

3280 




Mean Delay (msec) 
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BIS Network Delay Comparison Plot 



Traffic Intensity / Node (Kbps) 

- B_2087_NI □ RM 507 0 MAC Network 

• RM 638A a Printer 


Figure 4.1 BIS devices delay plot for simulation time of 1 second 
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BIS Network Delay Comparison Plot 
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Figure 4.2 BIS devices delay plot for simulation time of 2 second 
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BIS Network Delay Comparison Plot 
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Figure 4.3 BIS devices delay plot for simulation time of 10 second 



Throughput (Mbps) 


BIS Network Throughput Comparison Plot 



1 | i 1 * 1 1 1 1 1 1 1 1 1 

20 . 40 . 60 . 80 . 

Traffic Intensity/Node (Kbps) 


■ B_2087_NI □ RM 507 Q MAC Network 

• RM 638A a Printer Network 


Figure 4.4 BIS devices throughput plot for simulation time of 1 second 
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BIS Network Throughput Comparison Plot 
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Figure 4.5 BIS devices throughput plot for simulation time of 2 second 
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BIS Network Throughput Comparison Plot 
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Figure 4.6 BIS devices throughput plot for simulation time of 10 second 
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Non-lntensive Network Delay Comparison Plot 
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Figure 4.7 Non-lntensive network delay plot for simulation time of 1 

second 
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Figure 4.8 Non-Intensive network delay plot for simulation time of 2 

second 
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Figure 4.9 Non-lntensive network delay plot for simulation time of 10 

second 
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Figure 4.10 Non-lntensive network throughput plot for simulation time of 


1 second 
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Figure 4.11 Non-lntensive network throughput plot for simulation time of 

2 second 
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Figure 4.12 Non— Intensive network throughput plot for simulation time of 

10 second 
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Figure 4. 13 Intensive network delay plot for simulation time of 1 second 
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Figure 4. 14 Intensive network delay plot for simulation time of 2 second 
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Figure 4. 15 Intensive network delay plot for simulation time of 10 second 
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Intensive Network Throughput Comparison Plot 
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Figure 4.16 Intensive network throughput plot for simulation time of 1 

second 
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Intensive Network Throughput Comparison Plot 
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Figure 4. 17 Intensive network throughput plot for simulation time of 2 

second 
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Intensive Network Throughput Comparison Plot 
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Figure 4. 18 Intensive network throughput plot for simulation time of 10 

second 



CHAPTER 5.0 


CONCLUSION 

5.1 Discussion of the Simulation Results 

This paper has introduced the basic operating characteristics of the 
network installed at the ASRM site located in Iuka, Mississippi. An 
overview of the network topology, communication protocols, and hardware 
devices was presented. 

The main objective of the research was to model, simulate, and analyze 
the network to determine its performance. The two primary evaluation 
parameters used to judge the network performance were the throughput and 
the delay. The analysis of the ASRM network was simplified by using the 
commercial software BONeS. The ASRM simulation was built using several 
component from the BONeS library. 

From the results obtained it can be concluded that, for the BIS devices 
the mean delay per packet increases as the offered traffic intensity increases, 
while* 1 for the OIS devices all the links show a knee at a particular traffic 
intensity. The knee in the curve corresponds to the buffer of the bridge 
becoming filled. Thus the buffer capacity of the bridges does appear to produce 
a bottleneck for the network. From the throughput plots it can also be seen 
that the BIS network is the most heavily loaded network. This can be 
attributed to the 400 Macintosh workstations connected to the BIS. 
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Among all the sub— networks the Intensive buildings experience the 
lowest delay. The FDDI backbone causes only a negligible delay compared to 
the other delay-causing factors considered in section 4.2. 

The throughput for all the sub— networks increases linearly with the 
traffic intensity per node except for that of Gandalf terminal server in Room 
638B. This is because the Gandalf terminal server is modeled as a constant 
.traffic generator. The throughput plot for building 2029 intensive (B_2029_I) 
shows a very high value as compared to the throughput plots of other intensive 
buildings, because the workcell MTRQ, which is connected to it, has a data 
rate of 4.608 Mbps [3]. Thus it can be concluded that the workcell traffic does 
cause a significant effect on the workstation traffic. 

5.2 Validation of the Simulation Model 

Any simulation model must be validated before the results can be 
accepted. The BONeS modules developed for simulation were checked with 
the site engineers at ASRM for the validation of the modules. 

5.3 Verification of the Simulation Results 

The verification of the results was carried out using the throughput 
values obtained from the throughput plots. The delay plots obtained are 
highly stochastic in nature due to the heterogeneity of the network and the 
traffic flow. The BIS traffic is affected by the Non— Intensive workstation 
traffic and the Intensive workstation traffic is affected by the Non— Intensive 
workstation traffic and the workcell traffic. 
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From the definition of throughput we get the relation: throughput of a 
su b— network at a particular traffic intensity will be equal to the product of 
number of nodes in that sub— network and the traffic intensity. For the 
intensive network the throughput of the sub— network was calculated by 
adding the throughput of the each workcell in that sub-network to the total 
workstation throughput. The throughput value computed using this 
relationship was compared with the observed throughput value. A table of 
comparison between the simulation results and the theoritical values is 
presented below. The table shows that the simulation results agree with the 
calculated values. 



Table 5.1 Verification table for the BIS devices 


Link 


No 

No 


MAC 

Network 


80 


Printer 

Network 


56 


B_2087 

NI 


14 


RM 507 


57 


RM 

638A 


80 


of 

>des 

Traffic 

Intensity 

(Kbps) 

Through- 
put cal- 
culated 
(Mbps) 

Throughput observed (Mbps) 

1 sec 

2 sec 



20 

1.60 

1.8 

2.2 


40 

8.20 

3.4 

3.3 

3.2 

60 

4.80 

5.2 

5.0 

4.8 

80 

6.40 

6.8 

6.4 

6.4 


20 

1.12 

1.5 

1.2 

EH 

40 

2.24 

2.4 

2.4 

2.4 

60 

3.36 

3.6 

3.5 

3.4 

80 

4.48 

4.8 

4.6 

EH 


20 

0.28 

0.4 

0.3 


40 

0.56 

0.6 

0.6 


60 

0.84 

1.0 

0.9 




80 

1.12 


1.2 

1.2 


20 

1.14 

1.5 



40 

2.28 

2.5 

2.4 

2.4 

60 

3.42 

3.8 

3.6 

3.5 

80 

4.56 

4.8 

4.6 

4.6 


20 

1.60 

1.8 

1.8 

1.7 

40 

3.20 

3.4 

3.2 

3.2 

60 

4.80 

5.2 

4.8 

4.8 

80 

6.40 

6.8 

6.4 

6.4 
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Table 5.2 Verification table for the Non— Intensive network 


Link 


1001 


1045 


1010 


2066 


I 

3B 


1002 


2029 


No of 
Nodes 

Traffic 
Intensity 
(Kbps) * 

Through- 
put cal- 
culated 
(Mbps) 

03 

20 

0.06 


40 

0.12 


60 

0.18 


80 

0.24 

04 

20 

0.08 


40 

0.16 


60 

0.24 


80 

0.32 

10 

20 

0.20 


40 

0.40 


60 

0.60 


80 

0.80 

04 

20 

0.08 


40 

0.16 


60 

0.24 


80 

0.32 

01 

20 

0.72 


40 

0.72 


60 

0.72 


80 

0.72 

01 

20 

0.02 


40 

0.04 


60 

0.06 


80 

0.08 

09 

20 

0.18 


40 

0.36 


60 

0.54 


80 

0.72 


- 1 Throughput observed (Mbps) 


1 sec 


2 sec 


IB 


.36 

155 









































































































































Table 5.2 (continued) 
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Link 

No of 
Nodes 

Traffic 
Intensity 
(Kbps) ‘ 

Through- 
put cal- 
culated 
(Mbps) 

Throughput observed (Mbps) 

1 sec 

2 sec 

10 sec 

B 2030 
NI 

09 

20 

0.18 

0.30 

0.22 

0.20 

40 

0.36 

0.48 

0.47 

0.38 

60 

0.54 

0.68 

0.62 

0.56 

80 

0.72 

0.88 

0.80 

0.74 

B 1025 
NI 

01 ! 

20 

0.02 

0.03 

0.02 

0.02 

40 

0.04 

0.04 

0.04 

0.04 

60 

0.06 

0.05 

0.06 

0.07 

80 

0.08 

0.07 

0.08 

0.08 


Table 5.3 Verification table for the Intensive network 


Link 

No of 
Nodes 

Traffic 

Intensity 

(Kbps) 

Through- 
put cal- 
culated 
(Mbps) 

Throughput observed (Mbps) 

B 2031 
I 

15 

20 

0.30 

0.30 

0.30 

0.30 

40 

0.60 

0.60 

0.60 

0.60 

60 

0.90 

0.80 

1.00 

0.90 

80 

1.20 

1.20 

1.20 

1.20 

B 2029 
I 

24 

20 

0.48 

4.80 

4.60 

4.60 

40 

0.96 

5.10 

5.00 

5.00 

60 

1.44 

5.40 

5.40 

5.40 

80 

1.92 

5.80 

5.80 

5.80 

B 1016 
I 

43 

20 

0.86 

0.90 

0.70 

0.70 

40 

1.72 

1.40 

1.40 

1.40 

60 

2.58 

2.00 

2.00 

1.80 

80 

3.44 

2.60 

2.40 

2.50 

B 2030 
I 

09 

20 

0.18 

0.20 

0.15 

0.10 

40 

0.36 

0.30 

0.30 

0.30 

60 

0.54 

0.30 

0.40 

0.40 

80 

0.72 

0.30 

0.60 

0.50 
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5.4 Recommendations for Further Study 

Not intended to be a complete analysis, this thesis provides the basic 
concepts by which the ASRM network was evaluated. A more detailed 
analysis of the network can be accomplished. Parameters such as traffic 
intensity, packet size, and response times can be varied in order to gain a 
more accurate and diverse analysis of network performance. For example a 
simulation can be run with the packet length set to the worst— case condition 
of 64 bytes. However, this also means that building a simulation can be a 
complex task and the actual time to do the simulations can be very long. 

At this point in time, the Cabletron hubs used to connect the 
individual networks have been modeled in BONeS as constant delays. A 
detailed analysis of the Cabletron hubs can be performed. This analysis will 
allow a more precise and accurate model for the BONeS simulator to be 
built. In so doing, the results produced by the computer simulation can 
approach a higher degree of accuracy. 

It would be also interesting to see the effect of a different traffic 
pattern from the BIS devices on the Intensive and Non— Intensive networks. 
This analysis would help for example in estimating the effect on the whole 
network due to increasing the number of BIS Macintosh machines. The 
study of the effect of workcell-to-ASC traffic on Intensive and 
Non— Intensive workstations would be useful in drawing some important 
conclusions. Lastly analysis of the traffic flow external to the ASRM 
network would be useful to observe its effect on the BIS hub. 
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Figure A. 1 ASRM network Model 
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Figure A.4 Intensive building 2030 Model 
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B_2087_NI [ 29-Oct-1 993 1 5:1 7:34 1 



Figure A. 11 Non-Intensive building 2087 Model 
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Figure A. 12 Non-Intensive building 2029 Model 
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Figure A. 14 Non-Intensive building 2066 Model 







Figure A. 16 Non-Intensive building 1001 Model 




Figure A. 17 Non-Intensive building 1045 Model 
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Figure A. 18 Non— Intensive building 1002 Model 
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Figure A. 19 Non-Intensive building 1010 Model 
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Figure A.20 Non-Intensive building 1025 Model 
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Figure A.21 BIS Model 
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Figure A.22 ASC Model 
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Figure A. 32 MT8-MIM Model 
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CHAPTER I 


INTRODUCTION 

This document is the project report for the directed project dealing with 
the software simulation of a Cabletron Hub. This project is for partial fulfillment 
of the requirements for the degree of Master of Computer Science in the 
Department of Computer Science at Mississippi State University. This report 
describes the goals and the results of the project, as well as the methods used to 
implement and test the final model. 

Project Objectives 

The objectives of this project were two-fold. The first objective of this 
project was to design and build a model of the Cabletron Hub using the Block 
Oriented Network Simulator (BONeS) which was developed by Com dis co 
Systems, Inc. The second objective was to use this model in a network simulation 
to try to dete rmin e if the hub produced any bottlenecks that might be of 
importance to network designers, especially those involved in building the 
computer network at the Advanced Solid Rocket Motors (ASRM) plant in Iuka, 
Mississippi. 


Site Overview 

The Advanced Solid Rocket Motor (ASRM) facility at Yellow Creek near 
Iuka, Mississippi is part of a National Aeronautics and Space Administration 
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(NASA) program to substantially improve the flight safety, reliability, 
productivity, and performance of the space shuttle’s solid rocket motors. The 
ASRM is a replacement for the current space shuttle Redesigned Solid Rocket 
Motor (RSRM). 


Project Description 

The computer network system at the ASRM plant uses Cabletron Multi 
Media Access Centers (MMACs) for its network interconnection. By researching 
the documents provided by Cabletron Systems, Inc. (Cabletron Systems Inc. 1989; 
1992a-f), and by talking with the Cabletron technical personnel, it was possible to 
develop an understanding of how the Cabletron Media Interface Modules (MIMs) 
used at the ASRM facility interacted with each other. Using this information and 
the BONeS Block Diagram Editor, models were developed that would emulate 
the interaction and timing specification of the overall hub. By connecting the 
individual modules together, the completed hub could be used in network 
simulations designed to analyze the performance of the hub. 

Overview of the Report 

In the following chapters, each of the individual Cabletron modules will be 
discussed in more detail, as well as the BONeS models that were used to 
implement the modules. Questions that were brought up over the course of the 
research, and the answers derived by the research will also be discussed. During 
the research, it was sometimes necessary to make assumptions either to simplify 
the construction of the models, or simply due to the fact that some information is 
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proprietary and was unavailable to the researcher. The assumptions made, and 
the reasons for m akin g the assumptions, are also discussed in the report. 



CHAPTER II 


CABLETRON DEVICES 

The network structure of the entire ASRM complex consists of many 
separate networks (Moorhead et al 1993, 16). The networks make use of diff erent 
types of tra nsmi ssion media as well as different communication protocols. 
Cabletron Multi Media Access Centers (MMACs), known as intelligent hubs, are 
used to interconnect the individual networks. The MMACs allow Ethernet, Token 
Ring, and FDDI networks to be connected together regardless of the transmission 
medium (Fiber, Twisted Pair, Coax, etc.) used (Cabletron Systems Inc. 1992e, 3). 
The following sections describe the individual components that were modeled, as 
well as giving some important characteristics of each 

The MMAC Chassis 

The MMAC chassis is a modular unit that is used to hold the individual 
modules that mak e up the complete MMAC. Cabletron manufactures three 
different models of the chassis; they are referred to as the MMAC-3FNB, 5FNB, 
and M8FNB, which contain slots for three, five, and eight media modules 
respectively. The MMAC-M8FNB, the only chassis used at the ASRM site, can 
provide up to 168 Ethernet ports (Cabletron Systems Inc. 1992e, 11). The first 
slot in each chassis must be populated with a Management / Repeater Module 
such as the EMME. 
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Built into the back of the chassis is the backplane. Cabletron has 
developed a flexible backplane known as the Flexible Network Bus (FNB). 

Modules inserted into the chassis connect to this bus, and are then able to 
transmit and receive data on this bus. The modules can be "hot swapped", which 
means the modules can be inserted and removed without powering down the 
entire MMAC. 

The FNB consists of several smaller buses known as the Ethernet, 
Management, Power, Token Ring, and FDDI buses. The Ethernet bus is further 
broken down into the Ethernet A, B, and C buses. However, only the newer 
generation of multi-channel repeater modules such as the TPRMIM ran access 
the B and C c h annels. Due to the flexibility of the FNB, the MMAC-FNB can be 
simultaneously populated with Ethernet, Token Ring, and FDDI modules. 

The EMME Module 

The first slot in each MMAC must be populated with a M ana gement / 
Repeater Module (Cabletron Systems Inc. 1992a, 3.3). The MMACs used at the 
ASRM site all contain the EMME, which is a new generation Ethernet Bridge 
and Management Module. The new generation modules are capable of accessing 
the internal B and C buses. The EMME bridges the internal Ethernet buses A, 

B, and C to the external Ethernet bus D. Ethernet bus D is the bus that connects 
to the front panel of the EMME. 

The EMME is also capable of filtering traffic that passes through the 
bridge. The EMME stores the node addresses in an internal Source Address 
Table (SAT) capable of storing up to 8,191 Ethernet addresses (Cabletron Systems 
Inc. 1992e, 29). The EMME filters out packets whose destination does not reside 
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on the opposite side of the bridge. T his reduces the amount of traffic flowing 
across the bridge, thereby reducing the load on the entire network system. The 
database is "self-learning" and has a user configurable aging delay so that 
addresses that have not been active for a specified amount of t im e c an be 
removed. 


The FORMEM Module 

The Fiber Optic Repeater Media Interface Module (FORMIM) is a multi- 
channel 10BASE-FL repeater card (Cabletron Systems Inc. 1992e, 51). Multi- 
channel simply means that the module is capable of accessing the FNB (Ethernet 
channels B and C). The FORMIM-22 features 12 fiber optic ports mounted on the 
front panel. 

Using the multiple internal Ethernet buses, this advanced Repeater 
Module can support two additional fully functional Ethernet networks within the 
same MMAC. The EMME described above is used to bridge these networks to 
the other existing Ethernet networks. 

The FORMIM-22 utilizes the advanced Repeater Interface Controller (RIC) 
chip to provide full IEEE 802.3 compliant repeater capabilities to each port and 
each module on the MMACs internal Ethernet Channels. The RIC chip was co- 
developed by Cabletron and National Semiconductor (Cabletron Systems Inc. 
1992d, 10). 

All multi-channel repeater modules that utilize the RIC chip (RMIMs) can 
be configured by either software or hardware to operate in one of two modes. 
These modes are Ethernet B / C or Standalone. In the Ethernet B / C mode, the 
modules repeat packets independently between ports on the same module and 



ports on other modules connected to the same channel. In Standalone mode, the 
packets are not placed on the bus but rather are only repeated to other ports on 
the same module. Seven separately repeated Ethernet segments can be obtained 
using the MMAC-8FNB and seven RMIMs operating in Standalone mode. 

The CXRMIM Module 

The Coaxial Repeater Media Interface Module (CXRMIM) is the same as 
the FORMIM described above except that the 12 fiber optic ports (10BASE-FL) 
are replaced by 12 thin wire coax ports (10BASE-2). 

In addition to the 12 coax ports, the CXRMIM provides a user definable 
Ethernet Port Interface Module (EPIM) that permits the user to configure the 
module with a single port for a variety of media types. Network designers can 
choose from seven different types of EPIMs including an Access Unit Interface 
(AUI), twisted pair, fiber optic, and coax media. All EPIMs are "hot swappable" 
and can be inserted through the front panel of the CXRMIM. 

The TPRMIM Module 

The Twisted Pair Repeater Media Interface Modules (TPRMIMs) are fault 
tolerant multi channel 10BASE-T modules. The TPRMIM-33 and TPRMIM-36 
provide 13 and 26 10BASE-T connections respectively. 

The FDMMEM Module 

The FDDI modules manufactured by Cabletron Systems provide high 
performance Ethernet to FDDI bridging, as well as FDDI concentrator 
capabilities. These features allow for designs that include Ethernet to the 



desktop and FDDI to the desktop from the same MMAC (Cabletron Systems Inc. 
1992e, 51). 

The FDDI Management Media Interface Module (FDMMIM) is the first 
single cha nn el module discussed so far. Unlike the multi-channel E th ernet 
modules, single c hann el modules do not have the ability to access the FNB 
Ethernet B and C buses. The FDMMIM is a full performance Ethernet to FDDI 
bridge module. It provides the connections between a 10 Mega bit per second 
(Mbps) Ethernet network (regardless of the number of nodes or media type), and 
a 100 Mbps FDDI backbone. 

The FDMMIM connects to the FDDI backbone via two MIC connectors on 
the front panel. In the event that one of the FDDI rings is severed or broken in 
some other manner, the FDMMIM will automatically "wrap" to the secondary 
ring to continue communication. The FDMMIM also provides for an optical 
bypass switch. This is an external passive device which will provide optical 
continuity in case of power failure or other node failure. 

To communicate with the Ethernet network, the FDMMIM communicates 
with the Ethernet bus A on the MMAC backplane. Through this bus, the 
FDMMIM can communicate with every Ethernet module in the chassis. This 
limits the number of Ethernet connections through the same FDDI module only 
by the number of Ethernet connections installed in the MMAC. 

The FDMM EM-04 has all of the features of the FDMMIM described above, 
but also contains four concentrator ports for FDDI connections. The four 
concentrator ports are provided by the additional four MIC connections located on 
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the front panel. Using the concentrator ports, up to four Single Attached stations 
can be connected to the FDDI backbone. 

The MT8-MIM Modnlp 

The MT8-MIM coaxial concentrator module provides eight male Ethernet / 
IEEE 802.3 Access Unit Interface (AUI) transceiver attachments. Each of these 
AUI attachments can be connected to the AUI port of any network device. The 
MT8-MIM is a manageable module which provides all the functionality of a 
multiport transceiver, yet integrates into the MMAC chassis. 

Filtering and Forwarding Characteristics 
Only two of the modules that have been discussed are capable of filtering 
and forwarding data packets, the EMME and the FDMMIM. The EMME is an 
Ethernet to Ethernet bridge and has the capability of bridging the four Ethernet 
channels (Buses A, B, C, and D) together at "wire speed." This allows for four 
independently repeated Ethernet segments. The EMME documentation states 
that the EMME filters packets at the rate of 28,000 packets per second (pps) and 
is capable of forwarding packets at up to 20,000 packets per second (Cabletron 
Systems Inc. 1992e, 29). 

The FDMMIM module is an Ethernet to FDDI bridge. Packets that enter 
the Ethernet A channel are examined by the FDMMIM, and are forwarded to the 
FDDI network by the FDMMIM, if needed; otherwise they are just discarded. 

The FDMMIM likewise examines packets that enter the module on the FDDI 
network for possible forwarding to the Ethernet A channel. To transfer Ethernet 
to FDDI, or FDDI to Ethernet, the FDMMIM must first convert the packet from 



one protocol format to the other. The FDMMIM documentation states tha t the 
FDMMIM filters Ethernet packets at the rate of 14,880 pps, and filters FDDI 
packets at a rate of 446,429 pps. Packets are forwarded in either direction at the 
rate of 14,880 pps (Cabletron Systems Inc. 1992c, B.2). 



CHAPTER IE 


TECHNICAL INFORMATION 

In t his chapter the te chnical details that were uncovered d urin g the 
research phase are discussed. This information can be broken down into five 
distinct areas. The five areas include: hardware architecture, hardware port 
delays, repeater delays, bridge forwarding latency, and bridge buffering capacity. 

Hardware Architecture 

The first approach the researcher used was to try to model the Cabletron 
Hub using the hub’s actual hardware construction as the basis for the model. 

This included the modeling of the backplane of the hub and the protocols used to 
transfer data from one module to the other. This type of information proved to be 
unavailable due to proprietary concerns. Even if this information had been 
available, it is doubtful the researcher would have been able to develop an 
accurate model due to the immense complexity of the hardware. 

Since the performance of the hub is based on delays and throughput, it 
was decided to approach the model from a performance point of view. By 
ex amini ng the reported figures for delays and throughput of the modules, it 
should be possible to build a model that produces the same performance statistics 
as those reported by Cabletron Systems, Inc. 

By exa mini ng the Cabletron documents, and talking with Cabletron 
technical consultants, it was determined that delays were introduced by the hub 
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at three key locations: port hardware delay, repeater delay, and bridge delay. 

Each of these locations is discussed in more detail in the following sections. 

Port Hardware Delays 

There is a delay introduced in the data path at the point where the 
different physical media types are connected to the front panel. For example, 
there is a delay introduced by the Fiber Optic Repeater Media Interface Module 
(FORMIM) when it converts the incoming optical signal into an electronic signal. 
In the same manner, there is a delay when converting an electrical signal to an 
optical signal. Each module introduces a small delay in this fashion. 

Repeater Delays 

Another source of delay is the time required for the repeater hardware to 
retime and retransmit packets. The standard delay for a Cabletron repeater is 
1.55ps (Tom Bell, telephone interview, 16 September 1993). Data enters the 
MMAC via a port on the front panel of one of the MIMs. Before that data exits 
the MMAC, it must first pass through at least one repeater (Tom Bell, telephone 
interview, 16 September 1993). There are two exceptions to this rule, however. 
The first exception is a packet entering the MT8-MIM and exiting another port on 
that same MT8-MIM. Since the MT8-MIM is a transceiver module, data does not 
have to pass through a repeater. The standard delay introduced by the 
transceiver is .864ps. The other exception is when a packet enters one Ethernet 
bus, and exits another Ethernet bus. In this case the packet will pass through 
two repeaters (Tom Bell, telephone interview, 16 September 1993). 
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Bridge Delays 

The third source of major delay is the delay incurred by a packet when it 
passes through a bridge. A packet must pass through a bridge when it enters an 
Ethernet bus (Ethernet A, B, C, or D) and exits on a different bus. In addition to 
this Ethernet to Ethernet bridge, there is a FDDI to / from Ethernet Bridge in the 
FDMMIM module. Any packet passing between FDDI and Ethernet must first 
pass through this bridge. Packets that pass between Ethernet B or C buses and 
the FDDI module must pass through two bridges, the EMME and the FDMMIM 
(Tom Bell, telephone interview, 16 September 1993). The EMME installation 
guide reports that the latency of the Ethernet to Ethernet bridge is 91ps 
(Cabletron Systems Inc. 1992a, A.1). No latency was reported for the FDMMIM 
modules. 



CHAPTER IV 


BONeS IMPLEMENTATION 

In the following sections, a brief overview of BONeS is given along with a 
discussion of the methods used to model the port delays and delays introduced by 
the bridges. In addition to the delays, it is necessary to model the buffering 
capacity of the bridges. The method used to model the buffering capacity is also 
discussed in the following sections. It should be noted that BONeS does not 
actually care what physical media type is used, it deals strictly with data 
structures and specified delays. Before the discussion of the implementation, the 
assumptions that were made will be given. 

BONeS Overview 

The Block Oriented Network Simulator (BONeS) provides an interactive 
graphical environment for simulation-based analysis and design of a broad range 
of communication networks. BONeS includes an easy-to-use modeling and 
simulation environment, an excellent modeling library that is user extensible, and 
a set of powerful analysis tools. These features allow the user to concentrate on 
the modeling and analysis of the design rather than having to work with the low 
level details of simulation programming. 
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Assumptions Made 

The EMMS is actually a self lear nin g bridge. T his simply means that 
when the bridge is first connected, it does not know all of the addresses for the 
nodes that are connected to it; it must first "learn" their addresses. When a 
packet enters the EMME and its destination address is unknown, the EMME 
forwards the packet to all channels. After the EMME learns the location of nodes 
from their source addresses, it will start to filter packets from the network 
segments that do not contain that node, and will forward the packet to the one 
network that does. The addresses are stored in a Source Address Table (SAT). 
The EMME is capable of storing up to 8,191 addresses in this SAT (Cabletron 
Systems Inc. 1992e, 29). 

Since there are only about 200 nodes connected to the entire ASRM 
network, and since the "learning" process is significant only when a hub is first 
brought on line, the "learning" process and the SAT are not modeled. It is 
assumed that the hub already knows where the nodes on the network are located 
and that it will begin to forward packets to the proper locations immediately. 

Port Hardware Delays 

In order to simulate the different delays introduced by the hardware port 
connections, absolute delays were placed at the entrance and exit of each port on 
a module. The delays for each type of connection are given in the list below 
(Cabletron Systems Inc. 1992c, 2.7). 

1. Transceiver Port Delays : .864ps 

2. Fiber Optic Connections : ,900ps 

3. Other Connections : .51 ps 
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EMME Bridge Processing Delay 

According to the EMME installation guide, the EMME filters packets at 
30,000 pps, and forwards at 18,000 pps (Cabletron Systems Inc. 1992a, A.l). This 
did not agree with the numbers reported in the Multi Media Access Center 
Products Catalog (Cabletron Systems Inc. 1992e, 29). In this document, the 
filtering rate is reported to be 28,000 pps and the forwarding rate is reported to 
be 20,000 pps. When questioned, Cabletron’s technical personnel reported that 
the correct figures are 28,000 pps for filtering, and 18,000 pps for the forwarding 
capability, under ideal conditions with 64 byte packets. At first it was not 
obvious to the researcher how 18,000 pps could be obtained when the latency was 
reported to be only 91ps. At 91ps per packet, it seemed that the maximum 
number of pps would be l/91ps, which is approximately 11,000. 

When actually designing the model, however, the researcher discovered 
that by taking the delay introduced during the filtering stage, and adding the 
delay required in the forwarding stage to obtain 18,000 pps, the overall delay is 
very close to 91ps. This is shown by the equation: 

(1) 1/28,000 + 1/18,000 = 91.27ps 

Using the assumption that the bridge processing must be pipelined, a bridge 
model was devised such that the filtering and forwarding phases were working in 
parallel as they would in a regular pipelined architecture. Figure 1 given below 
shows the completed EMME routing module. 
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Figure 1. Block diagram of the EMME routing module 


As was stated earlier, the EMME has the capability to bridge together four 
different Ethernet channels. To model this capability, nine bridges were required 
in the EMME alone. A method had to be devised that would allow the nine 
bridges to act as a single multi-port bridge. This was accomplished by using 
Server Resources which are provided by BONeS. In essence, the nino bridges 
compete for a single CPU resource to obtain their processing times. If data is 
only entering one c h a nn el, then only one bridge needs processing time, and it has 
the full power of the CPU to itself. If all channels are active however, they will 
share the CPU resource. The result is that all bridges put together will have a 
total throughput of only 18,000 pps for forwarding, and 28,000 pps for filtering. 

FDMMIM Bridge Processing Delay 

The FDMMIM was modeled using the same pipeline principle that was 
used to model the EMME module. The FDDI filtering stage introduces a 
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1/446,429 second (2.24 ps) delay; the Ethernet filtering stage and the forwarding 
stage both introduce a 1/14,880 second (67.2 ps) delay. The completed FDMMEM 
bridge module is shown in Figure 2. 



Figure 2. Block diagram of the FDDI to CSMA/CD bridge 


Buffering Capacity of the EMME and FDMMIM 
The buffering capacities of the EMME and the FDMMIM were modeled 
using quantity shared resources which are provided by BONeS. This resource is 
basically a pool of tokens. The tokens are removed by a module called "allocate" 
and are returned by a module called "free". For each module a pool was created 
containing four million tokens. The four million tokens represent the four million 
bytes of buffer memory provided by the EMME and the FDMMIM (Cabletron 
Systems Inc. 1992a, A.1; Cabletron Systems Inc. 1992c, 1.7). 

When a packet first enters either the EMME or the FDMMIM, the module 
tries to allocate the number of tokens equal to the length of the packet in bytes. 

If there are not enough tokens available, then the buffer is full and the packet is 
discarded. If there are enough tokens, then they are removed from the pool, and 
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the packet is put into the queue for processing. If the bridge filters out the 
packet, then the tokens are returned to the pool by the bridge for use by another 
packet. If the bridge forwards the packet to another channel, the tokens are 
returned to the pool as soon as the packet successfully exits the module. 



CHAPTER V 


CONNECTING MODULES 

This chapter deals with the connecting of modules together to form the 
network hub. The manner in which the hubs are connected is important; invalid 
results are produced if they are connected incorrectly. 

Connecting to the EMME 

The EMME module is required in any hub that is to provide management 
or bridging functions to the Ethernet channels. In addition to the management 
and bridging functions, the EMME provides the repeater for the modules on the 
Ethernet A channel. 

The EMME module, shown below in Figure 3, has connections for four 
Ethernet segments. The connections are labeled A through D. Channels A 
through C represent the three Ethernet channels on the MMAC backplane. The 
fourth channel, channel D, represents the Ethernet connection on the front panel 
of the module. If the user does not intend to use all four channels, then the 
vacant channels must be "terminated" using the terminator provided by BONeS. 
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Figure 3. Block diagram of the complete EMME module 


The A channel of the EMME should be connected to the first generation of 
Ethernet MIMs such as the MT8-MIM. Unlike the repeater modifies, the first 
generation modifies depend on the management card to provide the repeater 
function. The FDDI management modules, such as the FDMMIM or FDMMIM- 
04, can also be connected to this channel. This will provide the FDDI to Ethernet 
bridging capabilities. 

When two or more modules are to be placed on the same Ethernet 
channel, the modules should be daisy chained together. On each module there is 
an Ethernet "In" channel and an Ethernet "Out" channel. The "Out" channel of 
one module is to be connected to the "In" channel of the next module. The last 
module in the chain must have its "Out" channel terminated using the ter min ator 
provided by BONeS. 
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The repeater modules such as the TPRMIM and CXRMIM can only be 
connected to Ethernet channels B and C. These modules have a built-in repeater 
and do not require the EMME to provide the repeater functionality. 


Connecting to the FDMMIM 

The FDMMIM module, shown below in Figure 4, has three basic ports. 
The first port is an Ethernet "In" port and is to be connected to the Ethernet A 
channel. The second port is an Ethernet "Out" port and should be connected to 
the next FDMMIM or FDMMIM-04 module or terminated if the FDMMIM is the 
last module in the chain. The third port is the connection point for the FDDI 
ring. In addition to this FDDI ring connection, the FDMMIM-04 provides four 
concentrator port connections. 


FDMMIM [ 1 8-Nov-l 993 1 6:5B.t>3 ] 





® OS Resource 

fP FDOI Flter Tima 
T P FDOi-CSMA^CD Forward Tim# 
fP Hub- ID 

t P FDOI Manager Number 


fp] Node name « port 2 (FDDI) 
fP| Node name * port 1 (camafod) 

fP TTRT 

fp| Sync Alooatbn 

[P] Sync Butler Size 

S T_Pr(0) 

|~F| Async Buffer Size Per Priority 
fP Ring Latency 

® MAC Overhead 

fM FDOI Ring Memory {port 2 ) 

fp] Queue Size of Bridge on port 1 (esma/od) 

j~P] propagation delay (cema/cd) 
f P Network* On "A" Channel 

fP Node* On FDDI Side Of Bridge 
fP] Propagation Delay 


Figure 4. Block diagram of the complete FDMMIM module 
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Media Interface Modules 

The Media Interface Modules (MIMs) all have two Ethernet connections on 
the back to connect to the "backplane" of the MMAC. Two connections are 
provided in order to daisy chain modules together. Each MIM also includes 
Ethernet connections for the ports located on the front panel of the module. The 
MT8MIM, an example of a media interface module, is shown in Figure 5 below. 
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Figure 5. Block diagram of the MT8MIM module 









CHAPTER VI 


VERIFICATION AND VALIDATION 

The main objective of the testing phase is to verify that the software 
models developed in the previous chapter produce the same results as the actual 
hardware devices. Before the actual experiments are described, it is first 
necessary to describe what the theoretical results of the models should be. Once 
the theoretical results are explained, the simulations used to test the models are 
described. Finally, the results of the test simulations are examined. 

Testing Background 

The two metrics used to determine performance of the hub are throughput 
and delay. Cabletron provides the throughput and delay measurements for the 
EMME and FDMMIM modules. As we will see shortly, the EMME and 
FDMMIM modules are the only modules that need to have these measurements 
specified. All numbers given by Cabletron assume optimum operating conditions 
for the EMME and FDMMIM modules (Maurice Shagnon, telephone conversation, 
18 October 1993). Optimum conditions include the modules’ not being required to 
perform management functions and the data packets' being at the minimum legal 
length of 64 bytes (Maurice Shagnon, telephone conversation, 18 October 1993). 

Why are the EMME and FDMMIM modules the only modules that have 
the throughput and delays specified? The EMME and the FDMMIM are bridging 
modules and are the only two modules that play an active role in the varying of 
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these two measurements. The TPRMIM, CXRMIM, MT8-MIM, and the other 
MEMs introduce fixed delays according to the type of hardware port they utilize. 
For these modules, the delay is constant. The EMME and FDMMIM modules, 
however, vary in throughput and delay according to the loads that are placed on 
them. This variance is due to the processing and buffering of the bridges within 
these modules. 

As was stated earlier, the non-bridge modules introduce a fixed delay in 
the path of the packet. Although this added delay is undesirable in the network, 
it works to the bridges’ advantage. When the full network is in operation, delays 
increase the possibility of packets colliding with each other. Collisions reduce the 
throughput of the network. To prove this, two simple tests were conducted. 

The first test involved a network with only two nodes. The first node 
tra n s mi tted data to the second node, and the second node collected statistics on 
the received throughput. Since there is only one source of traffic, there are no 
collisions on the network. 

The second test involved a network consisting of three nodes, two nodes 
transmitting data to the third node. Once again, the third node collected 
statistics on the received throughput. Since there are two sources of traffic, 
collisions are possible. 

The plots shown in Figures 6 and 7 display the results of the two tests in a 
graphical format. As can be seen from Figure 6, the maximum throughput 
obtained by the two node network is 5.476 million bits per second (Mbps). From 
Figure 7 , it can be seen that collisions have reduced the maximum bandwidth to 
5.445 Mbps. 
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Intensity Generated By Single Source (Mbps) 
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Figure 6. Plot showing maximum throughput achieved using one source 
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Maximum Received Throughput (With Collisions) 



Y Scale- 10*3 


□ Received Throughput Of Node 3 


Figure 7. Plot showing maximum throughput achieved using two sources 


A reduced throughput allows the bridge module to empty its buffer if the 
buffer has started to accumulate packets. Since collisions reduce the network’s 
throughput, it is more important to verify that the EMME and FDMMIM 
modules are producing the expected results when no collisions are present. Once 
the bridge modules are verified, the other MIMs can be added to the hub to 
ex amin e the overall performance of the entire hub when collisions are present. 

Protocol Maximum Throughput 

In order to understand the results obtained during the testing phase, it is 
necessary to understand the communication protocols used by the MMAC. The 
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two protocols that have been modeled include Ethernet and FDDI. The Ethernet 
frame format is shown below in Figure 8. 



Preamble 

Destination 

Address 

Source 

Address 

Frame 

Type 

Frame Data 

CRC 


64 bits 

4B bits 

48 bits 

16 bits 

36B-1 2000 bits 

32 bits 










Figure 8. Format of the Ethernet frame 


In addition to the frame size, the Ethernet protocol requires that a source 
keep a 96 bit gap between successive frames. This prevents one source from 
monopolizing the media. The total transmitted frame length is therefore 672 (512 
frame bits + 64 bit preamble + 96 bit interframe gap) bits long. When 
considering the interframe gap, the maximum available throughput is calculated 
as follows: 

(2) 10 Mbps * (576/672) = 8.571 Mbps 

As can be seen from the frame format in Figure 8, the minimum data size is 368 
bits, which is the value used in a 64 byte packet. T his observation is important 
because the BONeS probes used to measure throughput include only the user 
data. Therefore, the ma xim u m bandwidth available for user data by a single user 
on a 10 Mbps Ethernet network, using a 64 byte packet, is 

(3) 10 Mbps * (368/672) = 5.476 Mbps. 

Note that this is the maximum throughput obtained by the single source network 
as can be seen by Figure 6. 
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Fiber Distributed Data Interface (FDDI) has a total throughput of 100 
Mbps. The FDDI frame format is shown below in Figure 9. 


Preamble 

SD 

FC 
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64 bits 
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SD = starting delimeter. 
FC = frame control. 

DA = destination address. 
SA = source address. 

FCS = frame-check sequence. 
ED = ending delimeter. 

FS = frame status 




Figure 9. Format of the FDDI frame 


The size of the data field was made to be 368 bits to remain consistent 
with the Ethernet data size used in testing. Given 224 bits of overhead, and 368 
bits of data, FDDI has a maximum user throughput of 

(4) 100 Mbps * (368/592) = 62.16 Mbps. 

Since FDDI is a token passing protocol, a minimum interframe gap is not 
required between FDDI frames. There is a gap associated with the rotational 
latency of the FDDI ring. This latency reduces the throughput available to a 
single source, but only by a negligible amount. The rotational latency is therefore 
not included in the calculations. 

EMME Theoretical Results 

When verifying the operation of the EMME model, it was necessary to 
verify that the model exhibited the same filtering and forwarding characteristics 
as the real EMME. To accomplish this, the two characteristics were tested in two 
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independent simulations. The two simulations are described in the following 
paragraphs. 

The first simulation was used to verify that the EMME model produced 
the same filtering statistics as the real EMME. As was stated earlier, the EMME 
is capable of filtering packets at up to 28,000 pps when the packets are 64 bytes 
long. In order to generate the 28,000 pps, the input bandwidth to the EMME 
must be 14.336 Mbps (28k pps * 64 bytes per packet * 8 bits per byte). This 
value is greater than the 8.57 Mbps allowed by a single Ethernet channel with a 
single source. It was therefore necessary to use two Ethernet channels to input 
14.336 Mbps into the EMME. When using BONeS to record throughput, only 
user throughput is recorded. Since there are 368 bits of user data in a 64 byte 
packet (512 bits), the user throughput will be 

(5) 14.336 Mbps * 368/512 = 10.3 Mbps. 

What we expect to see is that the buffer in the EMME will begin to fill up at a 
much greater rate once the traffic entering the EMME exceeds 10.3 Mbps. The 
system that was used to test the filtering and bridging characteristics is shown 
below in Figure 10. 


d'3. 
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JD-EMME-4 Nodes-2 Sources-Part II [ 19-Nov-1993 21 :02:52 ] 



@ MAC Mem 1 

t P interarrfval mean 
t P Packet length 


? P EMME Forward Processing Tune 
fP EMME SAT Look Up Time 

If P Networks On A Channel 
IfP Networks On B Channel 
IfP Networks On C Channel 

If P Networks On D Channel 


MAC Stats > H 
Compute 


InM PH 


Write Address 
P Table to 

Info 


Of* 


Sink with 
MAC Stats-2 


Figure 10. Block diagram of the system used to test the EMME module 


The packets generated by the two workstations were addressed to stations 
that did not exist on any of the connected channels. Therefore, the packets 
entered the EMME, were processed, and were then discarded. 

The second phase of testing the EMME module dealt with the forwarding 
capability. As was stated earlier, the EMME can forward packets at rates up to 
18,000 pps. In order to generate 18,000 packets per second at 64 bytes a packet, 
it is necessary to generate data at 9.216 Mbps (18k pps * 64 bytes per packet * 8 
bits per byte). Remember that BONeS only reports user thr oughput which will 
be 


( 6 ) 


9.216 Mbps * 368/512 = 6.624 Mbps. 
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Since the maximum throughput available to a single node on an Ethernet 
network is 8.57 Mbps, it was necessary once again to use two of the four Ethernet 
channels to input data into the EMME. The other two Ethernet channels were 
used to remove the data from the EMME once it had been processed. The same 
system model that was used to test the filtering characteristics was used to test 
the forwarding characteristics. (See Figure 10.) 

Results of the EMME Tests 

The plots shown below in Figures 11 and 12 display the results of the 
simulations described above. According to Figure 11, the EMME model is capable 
of filtering packets up to 10.3 Mbps. The fact that the percentage used of the 
EMME buffer remains constant until just after the 10.3 Mbps mark proves this. 
Once the intensity is increased past the 10.3 Mbps mark however, the percentage 
of the EMME buffer that is used begins to increase. This shows that the EMME 
model is capable of handling traffic up to the 28,000 pps that is specified. 

From Figure 12 it can be seen that the model successfully forwards 
packets as fast as they enter the EMME up until the traffic intensity reaches 6.62 
Mbps. Once the user traffic intensity has reached 6.62 Mbps, 18000 pps are 
entering the EMME. When the intensity increases to a point above 6.62 Mbps, 
packets must be buffered and processed at a later time. The plot in Figure 12 
shows that the model can only forward packets up to 18000 pps. 

The plots displaying the results of the filtering and forwarding simulations 
indicate that the EMME model is indeed functioning as specified. The next 
module to be verified is the FDMMEM module. 
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Figure 12. Forwarding input and output traffic intensity of the EMME 
FDMMIM Theoretical Results 

As with the EMME model, it was necessary to verify that the FDMMIM 
model was operating correctly. The simulations were designed to test the 
throughput of the FDMMIM model. The FDMMIM module has a listed 
throughput of 446,429 pps when filtering FDDI packets, and a throughput of 
14,880 pps when filtering Ethernet packets. It was noticed that in order for the 
FDMMIM to filter 446,429 pps the frame could be at most 224 bits. The 
following calculation illustrates this fact: 

(7) 100 Mbps * (1 s / 446,429 packets) = 223.9 bits per packet 
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As can be seen from the FDDI frame format shown in Figure 9, in order for the 
FDDI frame to be 224 bits, the data field must be zero bits wide. This means 
the FDMMIM is capable of filtering packets as fast as the FDDI protocol can send 
the packets. The same calculation can be made for filtering of Ethernet packets 
as well as the forwarding of Ethernet packets to and from the FDDI network: 

(8) 10 Mbps * (1 s / 14,880 packets) = 672 bits per packet 

The 672 bits per packet can be understood if we remember that there are 576 bits 
in a 64 byte packet with a 64 bit preamble, and that there is a 96 bit gap between 
pairs of packets from a single source. By adding the 576 bit frame and the 96 bit 
interframe gap, we get 672 bits. Once again, the FDMMIM is capable of filtering 
and forwarding packets as fast as the Ethernet protocol can deliver them. 

When filtering packets, the FDMMIM is capable of filtering up to 446,429 
pps for FDDI packets. Remember that the rate of 446,429 pps occurs at 
maximum throughput of the FDDI network. Testing should reveal that the 
buffer utilization of the FDMMIM levels off when mayimum throughput is 
reached. If the buffer were to continue to fill up, then the processor would not be 
processing the packets fast enough. It was shown earlier in this chapter that 
given a 368 bit data field, the maximum user throughput available with FDDI 
should be 62.16 Mbps. Therefore, a plot of the buffer utilization versus the 
generated traffic intensity should level off around 62.16 Mbps. 

To test the forwarding capabilities of the FDMMIM model, a plot showing 
the throughput of data as it enters and exits the FDMMIM is taken Since the 
FDMMIM is capable of forwarding all types of packets at 14,880 pps, the plot 
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should reveal that the maximum throughput exiting the FDMMIM is about 5.47 
Mbps. This is the maximum user throughput available to a single Ethernet 
source, and the throughput needed to transmit 14,880 sixty-four byte packets in 
one second. 

Figure 13 shows the system that was used to test the filtering and 
forwarding capabilities of the FDMMIM model. The results of the simulations 
are discussed in the next section. 


FDMMIM-Test 1 [ 1S-Nov-1993 21 :5635 ] 
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Figure 13. Block diagram of the system used to test the FDMMIM module 


The Results of the FDMMIM Tests 

The result of the filtering test is given below in Figure 14. As can be from 
the plot, the buffer ceases to fill up once the incoming intensity reaches 
approximately 62.16 Mbps. As was explained earlier, 62.16 Mbps throughput is 
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the maximum user throughput available, and since the buffer is no longer 
continuing to fill up, the FDMMIM model is indeed processing packets at the rate 
specified, 446,429 pps. 



Figure 14. Plot showing result of the FDMMIM filtering test 


The result of the forwarding test is given below in Figure 15. As can be 
seen from the plot, the traffic leaving the FDMMIM on the CSMA/CD network is 
equal to the traffic entering the FDMMIM from the FDDI network. At 5.48 
Mbps, the FDMMIM is processing 14,880 pps. When the FDDI intensity passes 
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the 5.48 Mbps mark, the FDMMIM must buffer the extra data. The plot shown 
in Figure 16 shows the FDMMIM buffer beginning to fill up at a much greater 
rate once the FDDI traffic intensity passes the 5.48 Mbps mark. The plots shown 
in Figures 15 and 16 show that the FDMMIM model is perfo rming according to 
the given specifications. 
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Figure 15. Plot showing the result of the FDMMIM forwarding test. 
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Figure 16 . Plot showing the FDMMIM buffer utilization 




CHAPTER VII 


ANALYSIS AND CONCLUSIONS 

This chapter discusses some of the conclusions that have been drawn from 
the research and experimentation. Although much time and effort was put into 
the research, there are still areas that should be examined in more detail. These 
areas are discussed in the following sections. 

First Objective 

The first objective of this project was to research a Cabletron hub to 
determine operating characteristics and performance measurements for the hub. 
Once these measurements were known, a software implementation of the hub 
was to be designed using Comdisco’s BONeS application. 

This objective was successfully completed. Using performance 
measurements reported by Cabletron Inc., it was possible to derive a software 
model that produced the same results as the actual hardware devices operating 
under the same network conditions. 

Tests were conducted on the software models to verify their operation. 
Both the FDMMIM and the EMME modules produced the values expected. From 
the results it was possible to ascertain that under normal operating conditions, 
both the FDMMIM and the EMME could filter packets as fast as the protocols 
could deliver them. When forwarding, however, data may need to be buffered for 
later processing. 
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Second Objective 

The second objective of the project was to use the developed models in the 
simulation of the network at the ASRM site. This objective was not completed. 
The time required to run simulations under BONeS is on the order of days and 
weeks and therefore requires more time for further testing. 

It is possible, however, to predict the outcome by examining the results of 
the tests that were performed for the first objective. During the first objective, it 
was shown that both the FDMMIM and the EMME modules can filter packets as 
fast as the protocols can deliver the packets. Knowing this, it can be said that 
the Cabletron hub will not be overrun by the protocols when filtering is involved. 
When the modules are required to forward packets however, the data may indeed 
be buffered for later processing. Simulations must therefore be performed to 
determine if the load placed on the modules during operation will produce a 
significant amount of buffering. The tests from the first objective indicate that a 
very high network load is required for an extended length of time in order to fill 
the buffers up even one percent. 


Future Work 

There are still areas of this research that need to be studied in more 
detail. Now that models for the EMME and the FDMMIM have been developed 
and tested, models for the other media interface modules should also be 
developed and tested. Although these modules only introduce a fixed delay in the 
path of a packet, this delay is part of the overall delay of the packet while it is in 
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the network. For the ASRM site, this delay has to be kept to a minim um for the 
critical networks. 

Once the other media modules have been developed and refined, they 
should be used with the EMME and the FDMMIM modules to build a completed 
hub. This hub should then replace the existing hub modules in the ASRM 
simulation. This should give an accurate description as to whether or not the 
delays caused by the buffering will be a problem. It should also indicate whether 
or not the buffers in the bridging modules might possibly become full, thereby 
causing a loss of data. 
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MCS Project Contract 
for 

James F. Dement 
October 22,1993 


Project Title. 

Development of an object oriented model to represent the functionality of a 
Cabletron Hub. 

Project Description. 

Network protocols such as FDDI and Ethernet place restrictions on how 
networks using these protocols can be constructed. Restrictions such as a maximum 
number of nodes allowed, or the ma ximum distance between two nodes, severely 
limits the topologies available to network designers. To overcome the restrictions of 
distance and number of nodes, today’s network designers utilize what is commonly 
referred to as a network hub. 

This project involves the development of an event-driven, objected-oriented 
software model and simulation of a hub manufactured by Cabletron, Inc.. Cabletron 
hubs can be populated with man y different modules ranging from bridges to media 
interfaces for up to seven different types of physical media. Therefore, thi s project 
will center around the modules used in the Cabletron hubs that are currently being 
used by NASA's ASRM facility in Iuka, Mississippi. 

The model of the hub will be developed using Comdisco’s Block Oriented 
Network Simulator (BONeS). Using BONeS and the developed model, it will be 
possible to simulate the response and throughput of different network configurations 
under different operating conditions. Effects of traffic intensity or packet lengths can 



be studied without having to actually build the network. Other par am eters such as 
the size of buffers or the delays through bridges can also be varied and their effects 
studied. 

Deliverables. 

1. Working prototype of the object oriented model. 

2. Technical documentation. This will include technical characteristics that were 
considered for implementation and explanations of any assumptions. 

3. User’s Manual. This will describe how the models are to be connected and used 
when developing a network using BONeS. 
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Figure 19. Block diagram of the EMME transmitter node 

















